- From: John Baumgarten <jbaumgarten@apple.com>
- Date: Wed, 2 Feb 2005 07:56:11 -0800
- To: w3c-dist-auth@w3.org
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: > John Baumgarten wrote: >> 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. > > 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
Received on Wednesday, 2 February 2005 15:56:46 UTC