Re: BIND and live property value consistency

It's too bad about confusing existing clients when 'getlastmodified'  
changes on some resource without any body changes (the client may be  
completely unaware of bindings changse going on elsewhere), but I guess  
that's a less bad approach than possibly causing synchronization errors.

To me this seems like a perfect argument for requirements in the BIND  
spec, not just implementation advice.  Because of the synchronization  
problems clients would have if implementors do it wrong, we should add:

"WebDAV (RFC2518) states that the getlastmodified property value MAY be  
updated when changes are made to the resource even if the changes aren't  
to the resource body.  However, because clients may synchronize resources  
based on the value of this property, and because a binding to one resource  
at URL A may replace another binding at the same address, this requires a  
new getlastmodified date in order to trigger the client to synchronize  
properly.  Thus, the server MUST update the getlastmodified property value  
whenever a new binding is added to an existing resource as well as when  
REBIND is used."

Lisa


On Wed, 06 Jul 2005 16:39:21 -0700, Geoffrey M Clemm  
<geoffrey.clemm@us.ibm.com> wrote:

> I agree with Julian.
>
> For folks that may have missed Julian's previous explanations, if:
> - a resource at /x/foo.html has getlastmodified value of 57
> - a resource at /y/bar.html has getlastmodified value of 48,
> - /x/foo.html is deleted
> - BIND creates a second binding to /y/bar.html at /x/foo.html.
> then:
> - the getlastmodified value of /y/bar.html must be updated to be
> at least 49.
>
> This is illustrative of the general principle that the behavior
> of properties should be defined without trying to treat multiple
> bindings as a special case (i.e. any implementation that satisfies
> the definition of that property should be acceptable, and shouldn't
> be constrained by some "implementation advice" in the BIND  
> specification).
>
> Cheers,
> Geoff
>
> Julian wrote on 07/06/2005 12:18:30 PM:
>>
>> Lisa Dusseault wrote:
>> >
>> > Sure; how about this?  The general requirement and specific
> requirement
>> > don't have to be in the same place in the document so I've called them
>
>> > out  separately.
>> >
>> > General requirement: "All live properties defined in RFC2518 MUST have
>
>> > the  same value across all bindings to the same resource. "
>> >
>> > Specific: "The DAV:getlastmodified property MUST change when the
>> > underlying resource body is altered.  The property value MUST NOT
>> > change  when a new binding to the resource is created or when a
> binding
>> > to the  resource is removed.  If a collection has a
> DAV:getlastmodified
>> > property  then its value SHOULD change whenever its set of bindings
>> > changes  (including new bindings, removed bindings or bindings where
> the
>> > name or  target changes).  "
>>
>> Well, as I have explained multiple times, this doesn't reflect reality.
>> Servers *do* have to change the lastmodified date because of namespace
>> operations; otherwise it will loose it's HTTP-2616-defined semantics.
>>
>> > ...
>>
>> Best regards, Julian
>>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Received on Thursday, 7 July 2005 17:07:38 UTC