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

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 02:55:47 UTC