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

Julian-

See below.  Cheers and thanks for the feedback.

-Jake

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

> John Baumgarten wrote:
>> 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.
>
> 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

>
> If the SDK is supposed to work with pure RFC2518bis servers (is it?), 
> 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

Received on Wednesday, 2 February 2005 21:38:09 UTC