Re: ETags, next call, was: Notes on call from today ...

On Nov 27, 2005, at 7:59 AM, Julian Reschke wrote:
>
> In particular I'm surprised to hear that implementors of CalDAV 
> clients expect the servers to provide strong ETags for calendar 
> entries. A calendar server that has a ICS store has basically the 
> following options:
>
> - store the binary representation sent with PUT for every entry 
> (expensive), or
>
> - do not return an ETag at all after PUT, because the ETag returnen 
> upon GET will depend on what the server's default binary 
> representation of the calendar object will be (and that's unlikely the 
> same as sent by arbitrary clients)

Another option is for the server to store the calendar data in some 
internal format (e.g. nodes) and have a consistent way of constructing 
the entity from that.  As long as the server has an algorithm that 
generates the same bytes each time from the underlying data, it can use 
the same ETag.

It also doesn't matter what format the client sends the event in: the 
ETag refers to the octets the server sends, not to the octets the 
client sends.

It also doesn't matter if the client can request variants: for example, 
a server can keep one ETag around for the iCalendar version of the 
event, and a separate ETag for the xCalendar version of the event if it 
can generate two formats (both consistently).  Both ETags would have to 
change if the event data actually changed, of course.

>
> On the other hand, a server that implements RFC2616/RFC2518 would just 
> use weak ETags, allowing to reformat the content as long the semantics 
> stay the same.

How do weak ETags solve this?  What can a client really rely on if the 
weak ETag is the same, or different?  Do you believe a client could 
rely on weak ETags to do synchronization?  Wouldn't we need 
restrictions on what changes could be allowed before the weak ETag had 
to change in order to use weak ETags?

I haven't seen weak ETags be useful to clients except in two cases:
  - possibly for a client doing GET only (not an authoring client, and 
so it doesn't care about obtaining exact copy to author from)
  - a client that has inside information about what a server does -- 
e.g. a client with a coding dependency on the behavior of Apache which 
is to switch from a weak ETag to a strong one.

Lisa

Received on Monday, 28 November 2005 23:10:45 UTC