It's a semantic difference. We want to have as few semantic
differences as possible. We *did* add a couple if items that were
available elsewhere in the text protocol in ways that were redundant,
but they don't add functionality.
In the end, we'd like to avoid telling people they get some feature
with one protocol, but not the other.
The right thing to do here might be to add a getattr call and a
corresponding "touch" command to update flag and expiration.
I'm still not convinced knowing the expiration time is all that
useful in general. Data may still be overwritten, deleted, or
modified independently of the TTL, and it's not guaranteed to last
that long. Without positive confirmation of invalidation cmfeom the
server's point of view, you'll end up with all kinds of cache
consistency problems.
--
Dustin Sallings (mobile)
On Dec 15, 2007, at 8:01, Nicolás Lichtmaier <[EMAIL PROTECTED]>
wrote:
Attached is the most current documentation of the binary protocol
after
hammering through more details at the Yahoo! hosted hackathon today.
Wouldn't it at this stage be very easy to add 32 bits to the
response to send the "remaining TTL"? Any drawbacks to that? (Sorry
for being repetitive =) )
