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

Actually, I'm proposing to narrow the scope by adding the requirement  
of working with existing deployed offline-cache clients, which will  
limit the number of solutions that will meet the overall set of  
requirements.  This doesn't require a new feature.

Lisa

On Sep 12, 2006, at 11:01 AM, Julian Reschke wrote:

> 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:47:13 UTC