RE: 5.5 Write Locks and COPY/MOVE

This scenario does not have to be entirely automated. Out of band communication will generally suffice. It could be that the namespace is reorganised and the resource moved and an email sent to te community informing them of the changes made. I should then be able to select a new location for the update (client side stuff can be done without any mods to WebDAV), the moved resource should simply maintain its lock.

It would be nice to be able to locate a URI by the lock token because this would allow for the process to be automated (finally a really good reason to have lock tokens) but as far as I'm concerned, not absolutely essential. Perhaps this requirement could feed into the searching spec.

Cheers
Dylan

-----Original Message-----
From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
Sent:	Tuesday, February 17, 1998 2:01 AM
To:	'Dylan Barrell'; 'Yaron Goland'; 'WebDAV'
Subject:	RE: 5.5 Write Locks and COPY/MOVE



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 Tuesday, 17 February 1998 10:10:01 UTC