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

Ok, I'll wait a bit and see if others provide comments on any of this, but
given what you are saying here, I think I can imagine how to propose a way
of including GULP that meets various folks needs.


On 12/13/05 6:53 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> Cullen Jennings wrote:
>> 
>> This is clearly a very important topic - Julian points out he thinks it is
>> one of the few where if we can't solve it, we should not publish an update.
> 
> That was probably a bit radical, but locking clarifications certainly
> *are* what people expect from us.
> 
>> ...
>> We have the question is if the level of text in the GULP provides enough
>> information to for interoperable implementations. I have never argued that a
>> specification should tell people how they have to implement something but it
>> should be written in such a way that is implementable. From reading GULP, is
>> it clear how you might implement it? Is it clear that there is a polynomial
> 
> GULP wasn't around when we implemented locking, but as far I can tell,
> it closely describes the model we actually did implement after reading
> the spec, reading the rationals (Yaron's WebDAV Book of Why,
> <http://www.webdav.org/papers/> and having lots of conversations over
> here (which eventually resulted in people writing GULP down).
> 
>> time algorithm to implement locking? We could specify locks in many
>> different ways - one would be to describe the invariants of they system with
>> regards to the locks. This is basically the approach GULP takes. The other
>> would be to provide certain algorithmic rules that results in the same set
>> of invariants. This is the approach most specifications take. Both have
>> their place and useful. Now, we could normatively use algorithm and still
>> provide the GULP style description of the invariants. On the conference
>> call, I felt this was what people wanted. Did I totally miss this? Thoughts?
> 
> I have no strong feelings about this, as long as the result is as
> precise as what we have today with GULP. If there's a different approach
> to that which could work, I'm interested to see it.
> 
>> It is hard to call consensus on this because it is hard for people to
>> express their opinion until they see some text but unless I hear otherwise,
>> I will assume this is the path we are somewhat proceeding down towards
>> coming up with some text ask for consensus on.
>> 
>> Back to the first issue of what type of LOCKs are we building. This is by
>> far the more important issue. GULP provides one possible answer to this but
>> I'm not sure we have agreement on that. I will now refer to the PUT and
>> DELETE example that Julian put out earlier in this thread. My read of the
>> email is that we *do* agree on how the PUT would work. I'm not sure we agree
> 
> Yes, that's because PUT affects the "lockable" state of the resource
> (something we at some point need to define, and which RFC2518bis
> currently doesn't).
> 
>> on how the DELETE should work. We might agree but I can't tell.  Let's
>> assume we are working on a server that does not support bind. I'm not clear
>> how DELETE works. If /foo/a and /foo/b both point at the same resource, and
>> /foo/b is deleted, is there a guarantee that the resource will not be
>> deleted and that /foo/a will still point at the resource? Does the spec
> 
> No, there's no guarantee for that. Indeed this is the containment model
> RFC2518 *required* people to implement, and which we got rid of.
> 
>> allow the server to choose a model and some might allow it and some might
>> not? If so, do we need to allow the server to be able to select a locking
> 
> That's my understanding. RFC2518bis allows servers to vary, while BIND
> requires specific semantics (where destroying the resource and removing
> URL mappings to the resource in general are separate tasks).
> 
>> model that follows this? There seems to be questions around depth and depth
>> infinity, do we agree on these.
> 
> I think GULP works just fine.
> 
> If you do have an hypothetical server that upon DELETEing /foo/b also
> destroys the resource mapped to, and all other bindings to it, then yes,
>   you'll need the lock token even though the resource was only locked
> through /foo/a. The difference here is not in the locking model (it's
> the same), but in the implemented semantics of DELETE.
> 
> As a matter of fact, the same question could be asked regarding access
> permissions on the container collections. If you do have /foo1/a and
> /foo2/a mapped to the same resource, do yo need DAV:unbind privileges
> for both if you DELETE /foo1/a? The answer depends on what your server
> is doing upon DELETE.
> 
>> These are probably the wrong questions but what I am trying to do is
>> separate this into two parts. 1 is how locks work, 2 is how we specify them
>> in bis. On the topic of how it works, does anyone care to help me frame the
>> really key question to decide how it works?
> 
> I think the best starting point is indeed GULP, and to let people raise
> potential problems they see with that model.
> 
> Best regards, Julian

Received on Wednesday, 14 December 2005 05:07:25 UTC