Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings

>
>> I still think that the bindings draft makes it far more likely that a 
>>  client will try to detect whether two bindings are the same resource 
>>  and behave differently if they are.  For example, a client that is  
>> bindings-aware could try to speed up synchronization by using  
>> 'DAV:resource-id' and synchronizing only once per resource, rather 
>> than  once per binding.  The client could cache the 'DAV:acl' 
>> property (or  any other live property) for offline use.  If the 
>> client knows that all  bindings will have the same value for 
>> 'DAV:acl' then it only needs to  request that property once per 
>> resource.  OTOH if the client knows that  different bindings may have 
>> different values for 'DAV:acl' (or another  live property) then the 
>> client must ask once for each binding.
>
> Which is exactly the reason why RFC3744 says that DAV:acl will be the 
> same no matter what binding you use.

I took 'DAV:acl' as an example because it's one we're familiar with and 
we can see the consequences of error.  It's other live properties I'm 
worried about.
(BTW, where does RFC3744 say that?  I see lots of places where 
'DAV:acl' is defined with respect to a resource and the language is 
fairly precise about resources and URLs, so one might believe that this 
behavior is implicit, but I can't see where it says anything about 
bindings.)

>
>> I also worry that it's not enough for us to say that dead properties  
>> MUST be the same value no matter which binding is addressed but live  
>> properties MAY vary.  We don't have a reliable way for the client to  
>> tell which properties are dead and which are live.  Still, I could 
>> live  with that.
>
> Well, as you just pointed out, the difference between dead and live 
> properties is fuzzy. Also, the statement as proposed, sort of 
> *encourages* implementers to have live properties varying by binding. 
> IMHO, they shouldn't (as properties are part of the state of the 
> resource or computed based on the state of a resource), and thus 
> should not vary at all. My impression from earlier discussion was that 
> you don't buy that point of view, so I haven't tried hard to get it 
> into the spec. Should I now?
>
Even if I disagree with the conclusion -- perhaps *particularly* 
because I disagree with the conclusion and others may also -- I feel 
strongly that the decision should be reflected as a requirement in the 
specification.

Lisa

Received on Tuesday, 7 December 2004 17:45:32 UTC