Re: new proposed text for locking overview

On Wednesday, 07/07/2004 at 01:31 ZE2, Julian Reschke wrote:
> 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,
I don't understand how this is related.  As far as creation, typically to 
create a resource you do PUT or MKCOL.  And the resource appears at the 
URL you provide as an argument.   This is not the case for locks. 

> - a lock has a URI,
Are you referring to the lock-token?  It doesn't work the same way that 
URI's for typical resources work.   For typical resources, the URI is a 
URL.  This is not true for locks/locktokens.

> - a lock has state,
As do properties but we rarely refer to them as resources because that 
would cause confusion.  Instead we give them a different name, 
"properties" to avoid that confusion.    Of course, specifications that do 
properties more clearly as resources should feel free to also refer to 
them as resources.

BTW... I'm not saying a lock is a property.  I'm just providing a similar 
example of where we chose not to highlight the fact that something is a 
resource.

> - the state is observable indirectly through HTTP methods 
Again, not the same way as typical resources.  Only as a side effect of 
asking (PROPFIND) for the state of some OTHER resource.  That's weird.

And that's the only method locks and typical resources have in common. 

> and last but not least,
> - it's pefectly ok to implement locks as HTTP resources (for instance
> which would react to DELETE).
You can say that for just about anything in this world, but we don't. When 
we find reason to standardize what you just mentioned, we then begin to 
have a reason to call locks resources, but right now they act differently 
than what we typically think of as resources.  So although they (and just 
about anything else in this universe) can be called resources, it is not 
really helpful to do so... and because of the context, it's actually 
confusing.


> If you substitute "lock" by "lock resource" things sound much better.
It's less awkward as you say, but still a little.  It works better to just 
say "lock"
since adding "resource" detracts.


> 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).
Well...  we don't do that in this spec though so it's premature to 
add verbiage claiming that they are resources.  Adding the verbiage
without the supporting behavior just adds confusion. 
Because you might want to eventually make them directly addressable 
via typical HTTP methods, we shouldn't say they aren't resources either.
Instead we should be silent.


> > 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 agree.

> I just happen to think that things become much
> clearer by seeing it this way.
;-)