W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: new proposed text for locking overview

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 07 Jul 2004 01:31:48 +0200
Message-ID: <40EB3664.90505@gmx.de>
To: Jason Crawford <ccjason@us.ibm.com>
Cc: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>

Jason Crawford wrote:
> I'll try...
> 
> Because we tend to tend to think of words the way we've used them even 
> if they technically have a more generic definition.   A lock seems to 
> not behave like what we typically refer to as a resource.  There doesn't 
> seem to be a lot of overlap in their most important features and methods.

Well, I'd say they do.

- you can ask the server to create a new lock using LOCK, similar to how 
servers frequently create new resources upon POST,
- a lock has a URI,
- a lock has state,
- the state is observable indirectly through HTTP methods and last but 
not least,
- it's pefectly ok to implement locks as HTTP resources (for instance 
which would react to DELETE).

> You mentioned that a lock has a URI.   I think of the lock-token 
> identifying the lock, but the fact that it uses URI-like syntax is only 
> coincidental to me.

That's fine.

> If a lock is a resource, I'd expect to be able to substitute the word 
> "resource" for "lock" and have it sound reasonable.  I'm comfortable 
> saying that a lock acts on a resource, but I'd not be comfortable saying 
> a  resource acts on a resource.  Similarly... "depth-resource", 
> "exclusive resource", or "write resource".   I'd prefer to simply think 
> of resources as something that locks act upon.

If you substitute "lock" by "lock resource" things sound much better. 
The concept is similar to the version history resource in DeltaV. It's 
not strictly needed for many things, but making it an HTTP resource 
gives you a lot of advantages (such as properties you can observe 
*directly* though PROPFIND instead of indirectly through a specific 
REPORT).

> For me it feels better not to define a lock at all beyond it's behavior 
> rather than to say it's a resource.

The desire to define the *state* of a resource (what it must consist of) 
in a single place IMHO is independant of whether we actually *state* 
that it *is* a resource.  I just happen to think that things become much 
clearer by seeing it this way.

So far I've heard a resounding "of course" internally in our office, 
yours and Elias' feedback. Let's see what others think...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 6 July 2004 19:32:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT