Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

Cullen Jennings wrote:
> Right, no big deal but it seems like a XML database that say had a regular
> expression for mapping one URI to another could easily get multiple bindings
> to one resource. 
> 
> The questions was could you use the DB lock mechanism (or for that matter a
> files system lock) to implement DAV locks. Julian said this would not be
> compliant with 2516 which I believe but I don't yet understand why it would
> not be. 

If the server would use just the DB lock (on the resource), and nothing 
else, it wouldn't be compliant to several URL related locking 
requirements, namely that you can't MOVE a parent without providing the 
lock token (thus the URL of the locked resource is protected from 
getting changed), and the lock to disappear when the resource itself is 
moved. Both of these require the server to store the URL to what the 
lock request was sent with the lock.

> Now Lisa proposed a model for locking slightly different than GULP which
> would, by my understanding, would allow an implementation like GULP but
> would also allow implementation like the one I just described to also be
> compliant. For a server that supported BIND, it would probably have to be a
> GULP like implementation.

I'll assume you're referring to 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1282.html>?

Which reads:

LD> One could imagine the lock applying to the resource and to all its
LD> bindings, considering  the bindings to be part of the state of the
LD> resource.  If I recall, I think this is the model I'd always assumed
LD> until GULP.  With this model, if A and B are bindings to a resource,
LD> and a LOCK token to A is successful, then for the duration of the lock
LD> the token is required to change either A or B.

This implies that a binding is part of the state of the resource, and I 
think both RFC2518 and RFC3744 are very clear that it's not. Namely, in 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>:

'A write lock on a collection, whether created by a "Depth: 0" or 
"Depth: infinity" lock request, prevents the addition or removal of 
member URIs of the collection by non-lock owners.'

So this is clearly different from what RFC2518 says, so it's not a 
proposed model, but a change request.

LD> In today's server implementations, does a LOCK of depth 0 on a
LD> collection prevent MOVE from being used to change resource names inside
LD> the collection?  This is another possible case that might be different
LD> depending on whether bindings were considered part of the collection,
LD> part of the resource state, or both.

Checked and confirmed that servers indeed implement RFC2518 as written. 
I'm not sure why we're still arguing this.

> Now I have no idea what is best, but I am poking at the form of the
> argument. You are arguing the 4 servers tested are compliant with GULP
> therefore do GULP. However the 4 servers, by my understanding (happy to be
> corrected if I am wrong here), also are compliant with what Lisa proposed
> given GULP is a subset of it.

GULP not only describes the locking model in RFC2518, it's also 
implemented. Lisa's proposal describes something else. It's as simple as 
that.

> I strongly suspect that there are some DAV like servers out there that try
> to use file and data base locking mechanism to do locks - I don't know if
> they are 2516 compliant or not. I also suspect there are some servers that

They aren't, unless they keep the locked URL somewhere as well (of 
course they won't need to do that if there's only one, but then cnecking 
it on every namespace operation may get expensive).

> do run regular expression on URL to create multiple bindings to files on a
> file system and DELETE will remove both all at the same time. Again, don't
> know if this should be legal for a server or not but practically it does not
> make much difference for the client so servers will continue to do it.
> 
> I like the idea of looking at what is running code today to determine how to
> move forward. (I won't ask about if those 4 servers you tested can store gif
> files or not :-) 

At least one of them may not be able to do so for some URLs.

> I'd like to see this discussion have more on what the model should and and
> why. So far I can summarize it as:
> 1) gulp would probably work
> 2) an alternative model might work
> 3) some people prefer 1 some 2
> 4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is
> good
> 5) I'm not seeing the insights that help people understand why one model or
> another would be better or worse.

So far, I haven't seen a model other than GULP that indeed describes 
what RFC2518 says and what servers implement. Making a binding part of 
the state of the resource instead of the collection containing it is a 
non-starter, sorry.

> I really like the posts Dan and Jim where having on the meaning and
> implications of etags on PUT. I could read it and understand why one might
> want or not want various options.

Best regards, Julian

Received on Tuesday, 20 December 2005 09:08:38 UTC