Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518

John,

I come from a background of working mostly with file system network  
protocols (AFP, SMB, NFS, etc) which are designed to be used between a  
file system client and a file server. I first started working with  
HTTP/WebDAV a few years ago, I made a lot of assumptions that HTTP/ 
WebDAV would work like file system protocols. I've learned that a lot  
of those assumptions are wrong.

I think the abstract of rfc2616 makes it clear that my assumptions  
were wrong, "The Hypertext Transfer Protocol (HTTP) is an application- 
level protocol for distributed, collaborative, hypermedia information  
systems. It is a generic, stateless, protocol which can be used for  
many tasks beyond its use for hypertext, such as name servers and  
distributed object management systems, through extension of its  
request methods, error codes and headers [47]. A feature of HTTP is  
the typing and negotiation of data representation, allowing systems to  
be built independently of the data being transferred."

So, the Mac OS X WebDAV file system client and Apple's iDisk server  
are using WebDAV/HTTP as a file system protocol, and the WebDAV/HTTP  
protocols are generic enough for that to work. However, because MOVE  
and COPY are not guaranteed to be atomic (all-or-nothing behavior),  
because what you PUT to a server isn't guaranteed to be what exactly  
what you GET back, and because of other behaviors that are not  
guaranteed by the HTTP/WebDAV specs to work the way a specific client  
would *like* them to work, I've come to the conclusion that all a  
WebDAV file system client can do is guarantee interoperability with  
specific WebDAV servers -- those WebDAV servers which behave like file  
servers.

So, I agree with you that atomic MOVE and COPY operations are needed  
for *our* clients, but I also understand that the WebDAV/HTTP specs  
aren't going to guarantee that behavior.

- Jim

On Mar 15, 2006, at 9:30 AM, John Barone wrote:

>
> Well, I still don't see mixing and matching methods from various  
> specs. as a
> coherent way of addressing the notion of atomicity (all-or-nothing  
> behavior)
> in this spec. 2518-bis.  But, that's neither here nor there; the  
> bottom line
> is that Xythos seems to be the only ones who feel that this is a  
> useful
> addition to the spec., so I'll let this drop as well.
>
> -John
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, March 14, 2006 10:42 AM
> To: John Barone
> Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
> w3c-dist-auth-request@w3.org
> Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518
>
> John Barone wrote:
>>> Again, what's wrong with REBIND? You can implement REBIND without
>> implementing
>>> anything else in the BIND spec. For that matter, you'd probably want
>>> to
>> implement
>>> UNBIND as well (as DELETE shares the non-atomic properties with  
>>> MOVE).
>>
>> I don't understand what's proposed here.
>>
>> Are you proposing that we leave the 2518-bis spec. silent on this
>> matter, and simply implement pieces of the binding spec. to provide  
>> this
> capability?
>
> Exactly.
>
>> If so, that doesn't make any sense to me, since what we're really
>> talking about is a different spec. with different requirements.  The
>> way I see it, that has no bearing on this spec. or this discussion.
>
> Well, both specs are discussed here, and both are supposed to be  
> submitted
> to the IESG at roughly the same time.
>
>> If instead you're proposing that we add a method REBIND to this  
>> spec.,
>> with an appropriate definition; my concern is that REBIND has a
>> specific meaning that's fleshed out by the context provided in the
>> binding spec., but that meaning doesn't translate to the 2518-bis
>> spec., where we're talking about MOVEs, COPYs, and DELETEs, not  
>> BINDs,
> UNBINDs, and REBINDs.
>
> That seems to be a very theoretical argument, unless you can show  
> exactly
> how REBIND isn't what you need...
>
> Best regards, Julian
>
>

Received on Wednesday, 15 March 2006 19:16:03 UTC