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