Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Lisa Dusseault schrieb:
> 
> This draft has discussion of how subsequent rewrites might affect a 
> decision on how to return ETags in PUT responses when the content might 
> have been rewritten.  That's great, but there's another kind of 
> consideration entirely, and that's how a client that maintains an 
> offline synchronized store, or cache of resources, will be affected.
> 
> A likely real-world example is a CalDAV server that can augment the 
> information in a VEVENT: filling in attendee status, adding alternate 
> attendee addresses, or filling in location information, or adding a URL 
> where the VEVENT can be seen as a HTML Web page (think of calendar sites 
> like meetup and upcoming.org).  While a subsequent edit of the same 
> event might or might not result in the same outcome whether or not the 
> client downloaded the intermediate version, there's still a problem if 
> the cached/offline copy isn't as rich as the server copy.  A user who 
> sees the discrepancy will assume bugginess.
> 
> It would sure be great if existing clients that already do offline 
> synch, and might already encounter this case, would work appropriately 
> with a new mechanism improving the functionality of ETags on PUTs.

I do agree that this is an issue for which a new HTTP feature may be 
desirable, similar things apply to AtomPub clients using "foreign 
markup" (which servers may or may not preserve).

That being said, defining HTTP extensions is hard enough. Thus, I prefer 
to identify a single problem, and to propose a minimal solution to that. 
If enough people are interested to work on a broader issue instead, 
that's fine with me. However I feel that extending the scope is probably 
the best way not to get anywhere at all (but I'd be happy to find out 
otherwise).

Best regards, Julian

Received on Tuesday, 12 September 2006 18:40:50 UTC