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

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Wed, 27 Oct 1999 09:34:33 -0700

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:[email-masked]]
> Sent: Wednesday, October 27, 1999 6:08 AM
> To: [email-masked]
> 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
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 27 Oct 1999 13:16:29 -0400

From: "Yaron Goland (Exchange)" <[email-masked]>

   Geoff, if

OK, we actually are making some progress here.  The message you refer
to above is primarily about how it makes coding difficult for a client
writer, and that's been my major pushback ... I didn't see how this
could be the case.  (Note: I actually had a long response to that message
all prepared, but after rereading it, various "humorous" comments could
easily not be so funny from a different perspective, so I indulged in
some self-censorship :-).

OK, I always enjoy a good dramatization (:-).

Sounds about right to me, and you can even just re-use the code that you
would use today when you get a 302 back from accessing an unlocked resource!
Now I agree that a normal file system client doesn't know a 302 from a
sharp stick in the eye, but I'm assuming that a WebDAV client has been
web-enabled at least to the HTTP-1.0 level, in which case it's already
handling 302 status codes.

And as for that user, as soon as they unlock the file, that increasingly
irritated co-worker who's been waiting for them to *finally* release their
?*?!@*! lock so they can get their job done, will move that file to the
new place anyway, and the user will have to deal with it (without even
getting the friendly 302 to warn them!).

   to play with their file and it was gone!

I just don't see it.  The file dialog popped up and told them that the
file was moved.  Heck, I *wish* that Word would do that today instead of
keeping a long memory of all the places the file *used* to be.  I just
don't see users finding the concept of "moving a file to a new location"
to be as mind-boggling as you suggest.

For one reason, because they have to deal with it all the time!  If I
move a file (say in the Explorer), all of my other tools (on my desktop)
that thought they know where the file was come back with "file not found".
Here we're not saying "file not found", we're saying "file still found,
but it's at this new location, which I will now remember for you".
Now if only *all* my tools were this friendly!

   They will call to ask where the hell it went.

But the tool just *told* them where it went.  If the client is even a
little bit friendly, it will update it's "file list history" with the
new value.  As opposed to the current protocol, where if a lock times
out or gets deleted for administrative reasons (possibly because some
poor co-worker needs to move the collection containing the locked
resource :-), the user just gets told "sorry fella, not there
anymore".

   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.

A user being told "your file is now here" scares you more than locks
timing out and administrative lock removal?  We've already got the
second two things as part of the protocol.  None of the three are
likely, so it's not a "frequency of occurence" issue.

   user experience.

This is a good thing.  It used to be about coding difficulty (:-).
But I think the user experience issues are just as easy to address.

   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.

Well, actually, there's probably a very high chance that a client
developer, sane or not, will give their users a bad user experience (:-).

The question is: is the experience of being told that their file is at
a new location (which they have to eventually cope with anyway once
they unlock the file and the move occurs) a traumatic one at any
significant level, and in addition, is it *more* traumatic than the
experience of a user that needs to make a namespace change, but
*can't* because there's always some file somewhere in that collection
that has a lock on it.

   If the protocol mandates

Yes, the question is which proposal (if either) puts the developer in this
position.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 27 Oct 1999 13:37:07 -0700

Well, I actually tried to move the parent collection of a locked resource
using some existing DAV tools, and here's what happened:

User A: Opens document "/ejw/fun/survey.doc" with Word 2000. This locks the
document.

User A then goes and opens up Web folder on the desktop, displaying "/ejw/".
User A then asks to rename folder "fun" to "notfun". An error message comes
back, stating that the folder couldn't be renamed, but after manually
refreshing the Web folder, it appears that a new folder "notfun" and the old
folder "fun" are both still present. When the "fun" folder only contains
"survey.doc", after the rename both folders contain distinct copies of
"survey.doc".

When "fun" contains more resources than just "survey.doc" before the move,
the destination folder only contains these other resources, and does not
contain "survey.doc" (Xythos), or contains all resources, including
"survey.doc" (IIS 5 Beta 3). After the move, folder "fun" only contains
"survey.doc".

As I recall from RFC 2518, this is actually compliant behavior -- the move
was performed best-effort.

This suggests that part of the problem is the interplay between the new
binding semantics of move, and the desire to preclude best-effort moves.

- Jim

---

From: Greg Stein <[email-masked]>
Date: Wed, 27 Oct 1999 14:08:55 -0700 (PDT)

On Wed, 27 Oct 1999, Jim Whitehead wrote:
>...

I'm not particularly set up to test this myself at the moment, but mod_dav
should refuse the move entirely if you don't hold the lock. For a move of
a collection, it scans the source tree looking for locks.

(yes, you could argue there is a "better effort" than this... :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: [email-masked] (WJCarpenter)
Date: Wed, 27 Oct 1999 14:52:04 -0700

gmc> And as for that user, as soon as they unlock the file, that
gmc> increasingly irritated co-worker who's been waiting for them to
gmc> *finally* release their ?*?!@*! lock so they can get their job
gmc> done, will move that file to the new place anyway, and the user
gmc> will have to deal with it (without even getting the friendly 302
gmc> to warn them!).

A lot of the discussion recently seems to have been assuming that this
carpet-from-under-you movement is being done by someone else (or the
same person) using a WebDAV MOVE.  That seems *incredibly* unlikely
and occasional to me.  Though I'm sure that could occur sometime, the
most likely scenario to me, it seems, is some Very Powerful
Administrator moving things around directly on the server (or in the
database or in the shoebox or whatever).  It's hard for me to imagine
a document repository where the only possible access mechanism is
WebDAV.

Even if the WebDAV server implementors do a complete and thorough job
of tying LOCKing in with whatever other tools the administrator has
available, it is the nature of administrative activity that there will
certainly be a way to instantly nuke any LOCKs that get in the way.
This is RFC-2518 compliant, and one presumes that clients will have to 
muddle through this.

If you have a reasonable administrator, you'll get an email along
these lines:  "Tonight we're reorganizing the /whatsit/thatsit tree,
in accordance with blah-blah-blah.  Be sure to check in anything you
have out before you go home tonight or be prepared to look for it in
the new place."
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Keith Wannamaker <[email-masked]>
Date: Wed, 27 Oct 1999 17:14:49 -0400

> a collection, it scans the source tree looking for locks.

This is correct, it will fail without moving anything.

--
Keith Wannamaker
IBM HTTP Server Development
RTP NC, USA

---

From: Edgar Schwarz <[email-masked]>
Date: Thu, 28 Oct 1999 10:25:42 +0200

> This is RFC-2518 compliant, and one presumes that clients will have to
And if you allow a lock to move with a 302 the admin has a clean WebDAV
way to tell the locking user where his stuff has gone to instead of
the client and its user "muddling through this".
User:    Hey, my locked file is gone !
Support: Did you already look in your mailbox ? You were warned that
         your file would be moved and to which place.
But if it`s consensus that this method is user friendly, so be it.

Cheers, Edgar

-- 
[email-masked] ON/EUE1, 07191/13-3382         Niklaus Wirth:
Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag.
Albert Einstein:  Mach es so einfach wie moeglich, aber nicht einfacher.