RE: 5.5 Write Locks and COPY/MOVE

> 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
approach
to dealing with this.   I'd prefer in my application to avoid user intervention
in
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,
but
I don't want to throw a monkey wrench into the draft now.  My initial (safer)
suggestion
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
automatically
generated for copied resources.

J.

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