Re: WebDAV Bindings - Issue Yaron.AtomicDelete

On 2000年1月18日 ccjason@us.ibm.com wrote:
>...
> >>
> There are, I freely admit, circumstances in which a client MUST be able to
> ensure that a DELETE is issued atomically. Clients in those cases will have
> to choose to not interoperate with many WebDAV servers in order to gain
> atomic delete.
> >>
> These clients can interoperate with an old iterative server just fine if
> they also include 2518 support. That's their choice.
> 
> We have asked around and it seems that server authors appreciate and are
> willing to comply with semantic of an "atomic" removal of a single binding.
I don't recall being asked, nor agreeing with atomic operations. If that
binding happens to be a collection, then it will definitely be non-atomic.
[ also assuming this is the "final" removal of the collection ]
>...
> >>
> Let me clarify that DELETE was defined to not be atomic with malice of fore
> thought. The non-atomic delete language was the result of nearly three
> years of negotiations and represented a deep and broad consensus built up
> amongst a huge community. Might I respectfully suggest to the BIND authors
> that they should not be so ready to overthrow years of careful consensus
> building.
> >>
> We've asked around. Folks appreciate this behavior and are willing to
> support it.
Again: I don't remember being asked. Maybe I missed a post to this list?
Regardless, I am not willing support atomic deletions of collections OR
single, member resources. Note that I mentioned member resources here. I
delete a member resource in two steps: the contents and its properties.
Definitely non-atomic.
And with respect to the Apache web server, I will not even begin to think
of making it atomic (e.g. serialize all requests while a resource is being
deleted).
> >>
> Do not imagine that the lack of screaming on this issue reflects consensus.
> Rather it reflects the fact that most of the WebDAV community is too busy
> implementing RFC 2518 to pay much attention to BIND. The BIND
> functionality, while I believe it will be important to WebDAV, is a bit
> ahead of the majority of implementers so they just aren't reading or
> reviewing it, yet.
> >>
> We have asked around and we didn't accept silence as a response.
I was certainly silent. Either that, or I'm going senile and forget
responding to a question of atomicity. I certainly can't imagine replying
"sure, I can sure an atomic delete".
> >>
> The key reason DELETE was not allowed to be atomic (which certainly would
> have been a nice thing to be able to do) has to do with the way file
> systems work. Most file systems do not support depth operations atomically.
> So, for example, when you delete a directory what actually happens is that
> the program does a depth first walk of the directory tree and deletes all
> the individual files, walking backwards up the tree until finally deleting
> the parent directory.
> >>
> You've pointed out that this is a problem on your file system. We've found
> no other. We've tested it and our testing indicates that the MOVE option
> you mention below works. (We did not test with ACL's though... or multiple
> bindings.) We've also contacted folks at your organization and they
> didn't see a problem.
This is an undue complication: generate a unique name, rename the resource
to that new name, then process its removal. And again, mod_dav couldn't
even do this because of its separation between properties and contents: I
could move the contents away, but a PROPFIND could still return
properties.
>...
> >>
> There is then the third and final issue, WebDAV begins with a "D" for a
> reason. It's goal is to be distributed. Requiring atomic DELETEs would
> essentially hinder all but the most expensive of systems from being able to
> implement distributed namespaces across multiple physical servers. The
> reason being that the atomic requirement means that these systems will have
> to establish transactioning systems between themselves in order to issue
> DELETEs if they share namespace.
> >>
> It's only one binding. The goal isn't to be atomic, that's just a
> fortunate side effect.
It is *definitely* not a "side effect." mod_dav certainly does not do a
rename-then-delete. Therefore, I have to take explicit actions to achieve
that behavior. I don't even think that I could *ever* guarantee an atomic
DELETE operation.
>...
> >>
> As such I move that the atomic DELETE language be struck from the BIND spec
> on the grounds that it destroys interoperability, requires behavior that
> would preclude file system based systems from supporting WebDAV and
> significantly increases the cost of implementing WebDAV in a distributed
> manner.
> >>
I agree with Yaron on this one. Strongly.
> I believe I've addressed all of these above.
> 
> It is very clear that DELETE should not be iterative or accept partial
> results in a server that supports multiple bindings.
I think it is very clear that it shouldn't.
Stating your opinion of clarity doesn't make it so, nor does mine. But I
certainly can tell you right now that I won't be one of the "example
implementations" required for an IETF Standard.
> Legacy clients may
> invoke DELETE without knowledge of the potential dangers. Therefore, a
> simple DELETE should delete a single binding. --- There is no compelling
> reason (so far) not to support single binding delete and it simplifies the
I believe that I've given you one. With a good chunk of extra work and
serialization within the server, then it might be possible. But I am not
really up for trying to figure it out.
Cheers,
-g
-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 21 January 2000 17:31:02 UTC

AltStyle によって変換されたページ (->オリジナル) /