RE: Comments on the "new" 2518

You state that the SHOULD language surrounding the "best-effort" behavior of
MOVE allows us to implement the operation as "all-or-nothing" and still be
compliant with the spec.; fair enough.  However, I'd think that the SHOULD
language in a spec. should lean in the direction of the desired/expected
behavior.   From Xythos' perspective, "best-effort" is not the desired
behavior, but then again, we're just one voice.  If the belief is that
"best-effort" is the consensus for the desired behavior when MOVEing a
collection, then so be it.  However, if in future revisions the language
changes to a MUST, then Xythos would have to argue vigorously against such a
change.
 
 
> You are confusing two issues: how to marshall an atomic move request, and
whether 
> that marshalling is packaged up with other features.  We can easily
unpackage 
> the REBIND request into a separately supportable feature, if that is what 
> is desired.
 
I don't know that I was confusing these 2 issues at all, since I don't
recall you stating or implying that REBIND (or some similar method) could be
unpackaged and included in this spec., until now.  
If we were to add such a method to the 2518-bis spec., then I'd suggest
method names of MOVE-ALL, MOVE-ATOMIC, or MOVE-COMPLETE, rather than REBIND,
which just doesn't have the same meaning when taken out of the context of
the binding spec.
 
 
Regards,
 
-John
 


  _____  

From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] 
Sent: Thursday, March 09, 2006 1:05 PM
To: John Barone
Cc: 'Julian Reschke'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
w3c-dist-auth-request@w3.org
Subject: RE: Comments on the "new" 2518



John wrote on 03/09/2006 11:34:40 AM:
> So, Xythos' opinion is actually that MOVE should be atomic.  That's what
our
> customers tell us they expect, that's what we want to provide for them. 

I think there are two reasonable desires being expressed here: 

(1) Your customers want "move" (the logical operation they invoke from your
client) 
to be atomic.  Fair enough.  You should do what you can to satisfy that
desire. 

(2) Your customers want "MOVE" (the WebDAV method) to be implemented
atomically 
(and not "best effort") by your repository.  Fair enough.  You are of course

free to make MOVE be atomic in your repository (that is certainly what we
do). 
2518 says that it "SHOULD" be best effort, but given a "SHOULD" from 2518, 
and a "want" from my customers, I'll go with the "want" from my customers 
every time (:-). 

But note that neither of these desires imply that we need to change the 
definition of MOVE from "SHOULD be best effort" (as defined in 2518) to 
"SHOULD be atomic".  There is no point in doing that because it would just 
be misleading ... a large number (probably, majority) of WebDAV servers do 
not make MOVE atomic (unsurprising, since 2518 states that MOVE 
SHOULD be "best effort", which means non-atomic).  Changing the definition 
in 2518bis would just mislead clients into incorrectly expecting a MOVE 
to be implemented atomically on the server.  Any attempt to make this 
change is pointless because: 
- existing servers won't magically change their behavior on MOVE just 
  because the language in the new spec has changed 
- most of the servers that support best-effort MOVE do so because they 
  cannot implement atomic MOVE.  Given the choice of changing their
implementation 
  so that it fails all MOVE calls from a client (because it cannot guarantee

  they are atomic), or continuing to act in a 2518 compliant manner and 
  implements a best-effort MOVE, I have   no doubt as to which option they
will pick. 

So what is the only interoperable recourse?  Have your server implement 
atomic MOVE, and define an extension to the protocol that allows a 
client to say "I insist on an atomic MOVE".  There are two possibilities: 
add a new header to MOVE (that says "I want this to be atomic"), or add 
a new method whose semantics are "atomic MOVE".  The difference between 
these two is that with a new header, an old server may just ignore the 
header it doesn't recognize, and do the non-atomic MOVE anyway, whereas 
with a new method, you are guaranteed that an old server will just fail 
the operation.  When designing the Bind protocol, we concluded that the 
new method is preferable since the client can simulate the "fall-back 
to non-atomic" behavior by just issuing a MOVE after a failed REBIND, 
but cannot simulate the "fail if not supported" with just the header. 

> And
> honestly, I can think of a real good reason why I'd want to start off with
a
> whole collection, and end up with 2 incomplete collections, that have to
be
> cleaned up.  This not only causes problems for the user who performed the
> operation, but also, potentially, any users that had/have read access to
the
> collection(s) (source and/or target).   

The repositories that implement a best-effort move argue that this 
is what their users want.  Trying to convince them that their users are
wrong 
or that they do not understand what their users want is usually not a very 
productive use of any of our time (:-).

> I was trying to strike a middle ground, since what we're proposing is a
> change to the spec.  The bottom line, is that we'd much prefer the spec.
> changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and
then
> provide some mechanism (maybe Header) to indicate otherwise.  Yes, our
> proposed "compromise" would require clients to change, so in that sense
it's
> not ideal from our perspective. 

That's not a middle ground ... that is misleading clients into coding
against 
an incorrect assumption ... changing the spec has no effect on all the
existing 
servers that do a best effort MOVE, and all the server implementors who
believe 
that their customers prefer a best effort MOVE and therefore would not agree
to 
the spec change in any case. 

> We could change our client technology to
> make use of the proposed header, but other ubiquitous clients (i.e. Web
> Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise,
> and would result in a less than ideal solution for our customers. 

If you think that users of those clients would prefer that your server 
perform an atomic move (and fail a MOVE if it cannot be guaranteed to be 
atomic), your server is free to do so. 

>  I don't
> see the suggestion of implementing REBIND as a workable solution, since
that
> entails implementing/supporting an entirely different spec. for both
server
> and client, introducing a whole host of additional requirements and
> functionality. 

You are confusing two issues: how to marshall an atomic move request, and
whether 
that marshalling is packaged up with other features.  We can easily
unpackage 
the REBIND request into a separately supportable feature, if that is what 
is desired.  As indicated above, you cannot get some functionality from
existing 
servers by declaring in some future spec that what they are currently doing 
violates a new "SHOULD".  That is what would be unworkable.  Whereas you can

implement atomic MOVE on your server, and also upgrade your clients 
and servers to support an explicit REBIND. 

>  While Xythos can certainly choose to implement the Bind
> spec. on its server, there's nothing to say that clients (particularly the
> most ubiquitous ones our customers are using) would follow suite; in fact,
> I'd venture to say they wouldn't, at least not in the foreseeable future. 

I don't see how that is relevant to this discussion. 
The only reason you are implementing REBIND on your server is to be friendly

to those clients that explicitly want a REBIND.  For all 
existing clients, you just implement MOVE atomically, since you believe that
is 
what your users want. 

> Besides, what we're talking about is the basic WebDAV spec. (2518,
> 2518-bis), which has established client and server applications supporting
> it.  I don't see suggesting the use of REBIND (which means implementing
the
> Bind spec.) as particularly germane to this discussion.  The issue at hand
> is the behavior and functionality provided by the MOVE method. 

And that behavior is etched in the stone of many tens (hundreds?) of
thousands 
of existing servers.  That just isn't something that is up for debate.  So
the only 
relevant discussion for this topic is on how to marshall the new atomic
behavior.

Cheers, 
Geoff