W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: lock-null's Still Locked after MKCOL or PUT conversion?

From: John Baumgarten <jbaumgarten@apple.com>
Date: Wed, 2 Feb 2005 11:54:55 -0800
Message-Id: <4F7C336A-7554-11D9-9763-000A95A69B20@apple.com>
To: w3c-dist-auth@w3.org


Apple has announced and is now supporting an SDK for our operating 
system (Mac OS X) that wraps the WebDAV protocol into a framework that 
is highly compatible with other application development frameworks on 
Mac OS X.  This allows rapid development of application features that 
take advantage of our .Mac iDisk service, which is based almost 
exclusively on the WebDAV protocol.  (Some features preceded full 
development of similar ones in WebDAV, such as quota.)

The point here is not to make a product plug, but to explain that these 
SDK clients have a simplified view of WebDAV operations, with a focus 
on solving distributed application collaboration issues.  Back to issue 
(3.) below, they may not check for existence before locking.


On Feb 2, 2005, at 11:15 AM, Julian Reschke wrote:

> John Baumgarten wrote:
>> Julian-
>> The advantages of "Namespace-reservation" (NR) resources:
>> 1.  NRs do not have the "strange" behavior of existing for some 
>> methods, but not for others.
>> 2.  Legacy clients that use lock-nulls in the most common way should 
>> still work.
>> 3.  Conversely, the server is more forgiving for less robust or less 
>> protocol-savvy clients that unintentionally lock non-existent 
>> resources that they intend to use as collections.
>> 4.  The above points are achieved without further complicating COPY 
>> or MOVE operations, which have been highly optimized for performance 
>> in our environment.
> With 1, 2 and I agree (but that also applies to simply creating empty, 
> locked resources with no special behaviour).
> 3) is interesting; I'm not aware of any clients doing this (at least 
> our server product doesn't seem to have any clients suffering from 
> it).
> So to me this sounds like putting (still) additional complexity into 
> the server implementation that's unneeded (but as usual, your mileage 
> my vary). Of course things look different if indeed you have to 
> support clients that rely on 3). If you do, it would be interesting to 
> the WG to learn which clients these are, because they will break with 
> a pure RFC2518bis as well...
> Best regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 2 February 2005 19:55:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC