RE: Comments on 06 spec

It doesn't deal with the case where a whole subtree should be deleted where one or more resources are already locked (because DELETE is not atomic and can be partially successful).

I think we should be explicitly optimistic in the spec as it will cause little problems in practice because if the user noticed the inconsistency and performed a reload it is very likely that the resource being accessed will have been deleted, moved, copied too.

I originally made a reference to this problem about six months ago when I asked for publishing methods to be included in WebDAV. This would allow the principle manipulating the namespace to "unpublish" the effected namespaces (an atomic operation), perform the operation and the "publish" the results (another atomic operation). Nobody took much notice of this at the time.

I suppose that your server could perform implicit "publish" and "unpublish" operations when the namespace is manipulated (although this is likely to lead to performance problems)

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Tuesday, January 27, 1998 2:13 AM
To:	'Jim Davis'; Fisher Mark
Cc:	w3c-dist-auth@w3.org
Subject:	RE: Comments on 06 spec

Hold it, the spec does not state that GETs are unaffected by locks. It
states that GETs are unaffected by WRITE locks. This is only one kind of
lock. I know that a read lock spec will be released in the near future
(mostly because I have to write it). Additionally our syntax allows for one
to request multiple lock types simultaneous so one could, for example, ask
for a read/write exclusive lock. This would create the sort of atomicity
that has been asked for.
	Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Monday, January 26, 1998 10:42 AM
> To:	Fisher Mark
> Cc:	w3c-dist-auth@w3.org
> Subject:	RE: Comments on 06 spec
> 
> At 09:36 AM 1/26/98 PST, Fisher Mark wrote:
> >
> >Maybe I am assuming too much, but if I was a user of a

Received on Thursday, 29 January 1998 16:34:34 UTC