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

   From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

   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.

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 :-).

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

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

   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." 

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!).

   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!

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.

   So, just to re-iterate, this isn't about coding difficulty. This is about
   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
   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?

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

Cheers,
Geoff

Received on Wednesday, 27 October 1999 13:16:31 UTC