RE: why URL protection is not feasible when you version collectio ns

Geoff, if
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html
doesn't convince you why it is we won't handle 302s then frankly we aren't
going to be able to convince you.

The bottom line is, baring a change in policy (which is always possible)
Office and products like it will refuse to enable "save" functionality with
any server that allows locked files to be moved. The ramifications on the
user experience (NOT THE DIFFICULTY OF CODING) is simply too high.

Having spent a long time as a PM at MS I can tell you exactly how the
conversation will go:

Gee, so you're telling me that the user loads a document, locks it, wants to
manipulate it through other tools and randomly it can just... move? What the
hell are we supposed to do? Put up a dialog "Hello Dear User, sorry to
disturb you, but for some reason the file you are editing has been moved,
please don't panic, it is still locked, but um.. yeah... it's in this new
place now. Please make sure you remember this when you try to access it from
some place else." 

The support costs alone for dealing with the pissed off users would rob us
of any profit on that sale of Office. The worst part is that most users
won't be calling because they hate the fact that their locked file was
moved. They will be calling because they didn't understand the dialog, went
to play with their file and it was gone! They will call to ask where the
hell it went. Which means that the poor support tech has to figure out if he
is dealing with a file system problem, an Office problem, a server problem,
or what have you. I'm already having nightmares about the support costs.

As I said in section 4.7.1 of
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html:

When a company sells client software it usually has to give away a certain
amount of free support. If a user picks up the phone to use their free
support all the profit on that sale is generally negated as a function of
the cost of providing help services. 

As such any sane Office PM is going to "just say no"(tm).

BTW, I make no guarantees. I don't work for Office. I just work with them. I
am only passing on to you my own experience in having worked with them.

So, just to re-iterate, this isn't about coding difficulty. This is about
user experience. No matter what the group passes, no matter what the
standard says, there is absolutely 0% chance that any sane client developer
is going to give their users a bad user experience. If the protocol mandates
it then the developer has no alternative but to either be non-compliant or
to use another protocol. How about we don't put the poor client developers
into that position?

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Wednesday, October 27, 1999 6:08 AM
> To: w3c-dist-auth@w3.org
> Subject: why URL protection is not feasible when you version 
> collections
> 
> 
> 
> One of the key pieces of functionality that a versioning server can
> provide is the ability to version collections.  The versioning server
> remembers the states (revisions) of a collection (i.e. the list of
> internal members).  This lets a client roll back to a previous state
> of the URL namespace, hold the namespace fixed while it is making
> changes and then updating to the current state, or even let let
> clients make changes to the namespace in parallel and then merge the
> results when appropriate.
> 
> Now suppose you are a versioning unaware client, but you do know about
> locking.  There is a default workspace (containg the revision 
> selection
> rules that compute what revision of a collection will show up in the
> workspace) that all your requests work against.
> 
> Suppose you LOCK /x/y/z/foo.html.  The versioning server will
> automagically check it out into the default workspace, and lock the
> resulting working resource.
> 
> But it's not just /x/y/z/foo.html that is versioned, but also the
> collections /x/y/z and /x/y and even /x, just for good measure.  Now
> some other client wants to add a label to some revision of /x/y.  Is
> this OK?  Well, if locked resources cannot be renamed, before the
> server can let the label be added, it has to compute the revision
> selection rule to see if this would cause a new revision of /x/y to be
> selected in the default workspace.  If this new revision of /x/y
> renames the member named "z" to be "oldz", the server must fail the
> label request (or else /x/y/z/foo.html will be renamed
> /x/y/oldz/foo.html).
> 
> You have to run this check on *every* change to *any* metadata
> (e.g. label, activity), against *every* workspace that might use
> that metadata.  Thus the term "computationally infeasible" (:-).
> 
> So one alternative is the one I've proposed earlier ... require
> that *if* a server allows renaming of locked resources, then it MUST
> return a 302 indicating where that locked resource ended up.
> A server is of course free to refuse the move ... it's only servers
> that allow the move that need to do the tracking for 302 responses.
> Today's locking servers are all protocol compliant; versioning servers
> are protocol compliant; and clients just have to handle the occasional
> (but rare) 302 coming back on access to a locked resource.
> 
> There is another alternative: have versioning servers tightly
> constrain the default workspace so that URL protection is feasible
> (perhaps, only allow a single label rule).  Then define locking
> to have the above behavior whenever a Target-Selector header is
> included in the LOCK request (indicating a versioning aware client),
> but have the URL protection behavior if there is no Target-Selector
> header specified.
> 
> I believe this is a significantly inferior alternative, since it
> defines two subtly different locking behaviors based on the
> presence of a non-lock related header.  Its only benefit is that
> a versioning unaware client is protected from 302's.
> 
> Since there are at least a couple of non-versioning implementors
> on this list that prefer the 302 behavior, I believe it is not
> just a complexity introduced by versioning, but rather it is something
> that is actually simpler for some classes of simple servers as
> well.  I'd still like to hear a convincing argument as to why it
> is hard for a client to deal with a 302 on an access to a locked
> resource.
> 
> Cheers,
> Geoff
>