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

RE: 5.5 Write Locks and COPY/MOVE

From: Jason Crawford <ccjason@us.ibm.com>
Date: Tue, 17 Feb 1998 12:18:18 -0500
To: <ejw@ics.uci.edu>
Cc: <w3c-dist-auth@w3.org>
Message-ID: <0038300017848996000002L062*@MHS>
> 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?

In a subsequent note, an automated email notification was mentioned as an
to dealing with this.   I'd prefer in my application to avoid user intervention
this situation...

I'd like to propose something a bit different.   Brace yourself... :-)
"Persistant ID's".  :-)   I actually prefer PIDs over our URL-based approach,
I don't want to throw a monkey wrench into the draft now.  My initial (safer)
is to use it as a backup mechanism.  That is, one can also fetch resources
based on
the object's persistant ID (perhaps via DASL).  <details omitted>  It could be
a live
property so that although it moves with MOVED resources, a new PID is
generated for copied resources.

Received on Tuesday, 17 February 1998 12:19:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC