Re: new proposed text for locking overview

Jason Crawford wrote:

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

That's only "typical" for WebDAV. Outside WebDAV, new resources are 
created as an effect of POST every second (and in this case, it's the 
server that assigns the URL). I'd actually call that the typical case, 
for the simply reason that it happens so often.

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

What is a "typical" resource? And why is this relevant unless I say that 
a lock indeed is a "typical" resource?

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

As a matter of fact particular instances of WebDAV properties on a 
resource *are* resources on their own. We just don't have a common 
notation for their URLs. For instance we could have defined that the 
DAV:displayname property for a given WebDAV URL http://a/b has the 
following URL:

   http://a/b;displayname

and then we could have allowed DELETE/PUT/GET on it. Many say that this 
is what WebDAV should have done, because it would have avoided the 
current situation where property values can not be addressed by the 
common WebDAV methods.

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

OK. Does "urn:ietf:rfc:2518" identify a resource? Does 
"mailto:w3c-dist-auth@w3c.org"? None of them can be addressed using HTTP 
directly. They are still resources, just not HTTP resources.

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

Again, unless you define what you understand with "typical" and how this 
is relevant here....

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

I'd like to understand *why* you find that confusing? Because you 
usually only use the term "resource" when talking about HTTP resources?

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

Well, that's what the spec *does*. The term "resource" is only used in 
the introduction.

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

They technically *are* resources. If you're arguing with that statement, 
you should explain how this is incorrect according to RFC2396 (which is 
the relevant spec here).

Whether we should *say* that they are resources is a different question. 
We don't need to say it, but my feeling was that it helps understanding 
how they work.

> ..

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 July 2004 02:42:43 UTC