W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

RE: 5.5 Write Locks and COPY/MOVE

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 16 Feb 1998 17:00:30 -0800
Message-ID: <01BD3AFC.6434E680.ejw@ics.uci.edu>
To: "'Dylan Barrell'" <dbarrell@opentext.ch>, "'Yaron Goland'" <yarong@microsoft.com>, "'WebDAV'" <w3c-dist-auth@w3.org>


On Monday, February 16, 1998 7:01 AM, Dylan Barrell 
[SMTP:dbarrell@opentext.ch] wrote:
> B) I take issue with the base assumption of your statement that an
> administrator can move a file while a user is working on it and not have 
the
> user's program crash and burn. Ignoring the whole lock issue, if you move 
a
> resource that a user is actively editing with any of the common editing
> tools such as Hot Metal, Netscape, Office, or even notepad, the program 
will
> just fail. While it is true that some tools may be powerful enough to 
handle
> having their file moved from under them, lock or no lock, those tools do 
not
> form the majority and given the 80/20 rule of protocol design if we can 
meet
> the needs of 80% of the market, which we clearly do on both the client 
and
> server side, then we have succeeded.
> [Dylan Barrell]  These are old-style file-system based editing tools. 
File systems are not a good collaborative authoring infrastructure. WebDAV 
is supposed to provide this infrastructure. Surely we can do better than 
this 20 year old metaphor?
>
> If you remove the locking issue (for example a WebDAV server which
> does not support locking), then you have no way of stopping anybody
> who has sufficient permissions (eg the administrator) from doing anything 
> with the files that you are editing, so the authoring clients are going 
to
> have to be able to deal with this problem anyway.

For a WebDAV client to handle resources being moved out from underneath 
them would either require some form of notification, or the client 
submitting an If-Match or If-State-Match header to indicate what the client 
thinks the current state should be.  For the client to know the new 
location, the notification message would have to indicate the new location 
of the resource, or the request on the old location would have to respond 
with a "Moved Permanently" message.  Neither of these solutions depends on 
the lock remaining current.

It seems to me the requirement you are proposing, Dylan, is that the client 
must be able to determine where a resource has moved after a move (this is 
a new requirement for WebDAV), and that the client must then be able to 
continue editing at the new location as if the move hadn't occurred.  Is 
this right?

- Jim
Received on Monday, 16 February 1998 20:54:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT