RE: Can you move a locked file?

We are going in circles. You have made the "server can always say no"
argument before and I have explained why I don't believe that philosophy is
workable:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html.

There are two differences in your arguments this time.

#1 - Clients must be able to deal with 302s anyway.

Clients do not have to currently deal with a 302 while their lock is
outstanding because the lock prohibits the file from being moved. The only
way a 302 could occur is if the lock failed and the client will treat that
as a catastrophic error.

For example, today if you try to use Office 2000 against a level 1 WebDAV
server Office will disable "Save..." functionality and only allow "Save
As...". The reason is that our users are trained to have very high
expectations regarding the reliability provided by "Save" where as they have
no expectations regarding "Save As..." Without namespace locking support we
can not meet those expectations, so we are forced to disable "Save..."

#2 - Mitigating features such as lock monitors and e-mail notification are
becoming so cheap that they can be relied upon being widely available.

Speaking from personal experience having helped to develop products which
provide for e-mail tracing, your expectations of their pricing are
unrealistic. Such systems are currently priced in the hundreds of thousands
of dollar range and I know of some new ones that will only be in the
thousands of dollar range. However it will be many years before they hit the
$200 OS range. Even were they widely available our users would refuse to use
them in practice because of the awful user experience they create. Irit
doesn't want to receive a message telling her that Joe has moved her files.
She just doesn't want her files to move.

I believe this comes down to one and only one issue. Will allowing locked
files to be moved cause an interoperability problem? As I previously argued,
I believe the answer is yes. You believe the answer is no. Neither of us
seems to be convincing the other.

Since we aren't making any real progress might I suggest we table this topic
until the next IETF? We can discuss this in our usual manner, an
unbelievably good/expensive meal followed by pistols at 10 paces. 

I checked out
http://www.zagat.com/search/results.asp?QueryType=RecordSet&strCategoryType=
restaurant&handler=byCategory&sortBy=CategoryRestaurantRank&fList=10001&loca
leID=7&searchPhrase=Favorite+Restaurants for ideas, Kinkeads looks both good
and close. L'AUBERGE CHEZ FRANCOIS actually sounded perfect given our mutual
preferences but it is a good hour away from the hotel. GERARD'S PLACE also
sounded good but I could use a bit more of a boisterous environment. It will
cover the noise of the gun shots. You remember the trouble we had last time.
The gun shots scared away all the cabs!

					Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Sunday, October 24, 1999 11:19 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Can you move a locked file?
> 
> 
> 
>    From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
> 
>    While I understand your justifiable fear that the access 
> linearization
>    caused by locks will hinder collaboration you must 
> understand that the
>    reason my users use locks is exactly that - they want to PROHIBIT
>    collaboration.
> 
> Then they should just make sure to buy a server that blocks MOVE's of
> locked files (which I agree a server should be able to do).
> 
>    For your users, WebDAV is a great way to powerfully leverage the
>    collaborative features of the web.
> 
> Which means they probably will instead chose a server that does lock
> tracking and returns 302's.
> 
>    Our two user's needs are in direct conflict.
> 
> So they buy different servers, but clients and servers can use the
> same protocol ... and everybody is as happy as one can 
> reasonably expect.
> 
>    You have proposed two mitigating technologies, lock 
> monitors and auto-email
>    notifications. Even if I could include those in a $200 OS 
> product (which I
>    can't)
> 
> I feel compelled to point out that $200 times 10 million users equals
> 2 billion dollars (:-).  Also that the current complexity of that $200
> OS product makes lock monitors and auto-email an unmeasurably small
> increase in complexity.  But then again, probably the last thing it
> needs is even an unmeasurably small increase in complexity (:-).
> 
>    I would not do so anyway because my users do not want to 
> have to deal
>    with the ramifications of these technologies. My users do 
> not want to get an
>    e-mail telling them their files have moved. They just want 
> their files to
>    stay where they were put.
> 
> Fair enough.  So we make sure that the protocol allows their 
> server to refuse
> to do the moves.
> 
>    Given the contradictory needs of our user bases I see two choices.
> 
>    Choice 1 - We agree to disagree. Deciding the problem is 
> irresolvable we
>    create two types of locks in WebDAV. This, of course, 
> destroys any hope for
>    interoperability and puts blocks in the road of my users 
> as they "grow" from
>    their current "private data world" model to a more open 
> "collaborative world
>    model."
> 
> Bad choice.
> 
>    Choice 2 - We agree that locks, as unfortunate as it may 
> be, must lock the
>    namespace and accept this limitation as the cost of 
> bringing the widest
>    number of users into WebDAV.
> 
> What about choice 3:
> 
>    Choice 3 - The protocol allows a server to either refuse the move
>    (returning "locked" status) or to promise to track the 
> move and return
>    302's as appropriate.  No problem for the clients, since 
> they have to
>    deal with 302's anyway, and no problem for the servers, 
> since they can
>    do what they believe is the right thing for their users.  Then we
>    let the market decide which server was right ... and all the while,
>    we have one common protocol to interoperate with.
> 
> Cheers,
> Geoff
>

Received on Sunday, 24 October 1999 15:48:49 UTC