- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 16 Feb 1998 17:00:30 -0800
- 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 UTC