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

From: John Baumgarten <[email-masked]>
Date: Tue, 1 Feb 2005 18:13:04 -0800

BTW, at Apple (.Mac, that is) we will be moving away from lock-nulls 
toward a 2518bis-06 style treatment of "namespace reservation".  As 
suggested, we create a zero-byte locked resource, but we add with a 
special property "namespace-reservation" in our server namespace.  The 
value of this property is the lock-token that created it.

We allow the following "legacy" behavior on a namespace-reservation 
resource:

1. If converted by any PUT, the special property is removed.  Thus the 
resource is no longer a "namespace-reservation".

2.  A MKCOL is allowed on this resource if the namespace-reservation 
property is still present, which then removes the special property.

3.  If an UNLOCK method is successfully executed on the resource 
passing the lock-token that created the namespace-reservation, while it 
still possess the special property, the resource is deleted.  
Successful execution requires ownership of the lock.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 14:41:24 +0100

John Baumgarten wrote:
> 3.  If an UNLOCK method is successfully executed on the resource passing 
> the lock-token that created the namespace-reservation, while it still 
> possess the special property, the resource is deleted.  Successful 
> execution requires ownership of the lock.

So, in the end they behave again like the original lock-null resources? 
What exactly is the point in making that change then?

Best regards, Julian

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

---

From: John Baumgarten <[email-masked]>
Date: Wed, 2 Feb 2005 07:56:11 -0800

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.

-Jake

On Feb 2, 2005, at 5:41 AM, Julian Reschke wrote:

>> special property "namespace-reservation" in our server namespace.  
>> The value of this property is the lock-token that created it.
>> 1. If converted by any PUT, the special property is removed.  Thus 
>> the resource is no longer a "namespace-reservation".
>> passing the lock-token that created the namespace-reservation, while 
>> it still possess the special property, the resource is deleted.  
> So, in the end they behave again like the original lock-null 
> resources? What exactly is the point in making that change then?
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 20:15:29 +0100

John Baumgarten wrote:
> 1.  NRs do not have the "strange" behavior of existing for some methods, 
> but not for others.
> 
> 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

---

From: John Baumgarten <[email-masked]>
Date: Wed, 2 Feb 2005 11:54:55 -0800

Julian-

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.

-Jake

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

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 21:15:13 +0100

> The point here is not to make a product plug, but to explain that these 

Jake, there's no problem at all with talking about specific clients. In 
fact, this mailing list historically has seen little direct feedback 
from client implementers, so any kind of feedback is very valuable.

> SDK clients have a simplified view of WebDAV operations, with a focus on 
> solving distributed application collaboration issues.  Back to issue 

Just checking: the SDK allows people to write code without any knowledge 
of WebDAV protocol, and potentially enables them to write code that 
basically relies on the "classic" lock-null resources (LOCK uri then 
MKCOL uri, ...)?

If the SDK is supposed to work with pure RFC2518bis servers (is it?), 
we're facing a problem here. Did you consider to *also* deprecate this 
kind of operations?

Best regards, Julian

---

From: John Baumgarten <[email-masked]>
Date: Wed, 2 Feb 2005 13:37:35 -0800

Julian-

See below.  Cheers and thanks for the feedback.

-Jake

On Feb 2, 2005, at 12:15 PM, Julian Reschke wrote:

>> 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.
>
> Just checking: the SDK allows people to write code without any 
> knowledge of WebDAV protocol,

Yes

> and potentially enables them to write code that basically relies on 
> the "classic" lock-null resources (LOCK uri then MKCOL uri, ...)?

They do not expect a locking operation to preclude a resource from 
being a collection, so yes

> we're facing a problem here.

Currently the SDK only works with .Mac, but we supply "usage 
guidelines" that would result in desired behavior most of the time, 
with servers supporting either 2518 or 2518bis or our compromise.  
Specifically, check for existence first.

However, we have some "clients" (actually other web-servicing 
applications) with very high transaction rates and a high probably of 
multiple concurrent operations on the same resource.  So retaining a 
lock-with-create-but-allow-collection scenario solves some tricky 
timing issues.

Since our service tightly integrates a high-volume web pump with WebDAV 
"write" operations, providing sufficient performance while maintaining 
method transaction integrity is quite a challenge.

> Did you consider to *also* deprecate this kind of operations?
>
> Best regards, Julian