- From: Jason Crawford <nn683849@smallcue.com>
- Date: Thu, 6 Mar 2003 10:03:41 -0500
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Brian Korver" <briank@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> > Were you thinking that this header (say "Atomic-Operation:") would be > > used for only MOVE, or for all of the relevant operations (COPY, > > DELETE, etc.)? > > Actually, I'd really prefer not to define additional headers. > > Thinking of it, we *also* can't agree on the right DELETE semantics (see > separate discussion). So one way to address this would be to leave DELETE > and MOVE as they are, and to add > > - UNBIND (that really really really removes bindings, thus has the DELETE > semantics currently specified by the BIND draft) and > - RENAME (which would be a true MOVE that would fail when the server can't > implement it as internal namespace operation). Just a couple thoughts that I'm not going to have time to join in a coherent manner... My initial opinion when I saw this posting a day ago was that RENAME wasn't necessary. I don't recall now why I said that. It might just have been that it's less necessary than DELETE... but the recent case of the deletion before MOVE overwrite would change that view. If I recall any other reason why I thought RENAME wasn't necessary, I'll speak up. I'm okay with UNBIND (and I can explain why later) except... We have shown that atomic DELETE it should be implementable and the case of a partially finished MOVE with overwrite looks really bad to me. I'm not sure we should let servers do that. (I have an equivocating thought on this that I'll hold in reserve. :-)) So if they can implement the apparently atomic DELETE for MOVE, then they should be able to do it for DELETE itself. Previously we've discussed both headers and UNBIND. They were rejected. I don't recall why though, so we probably should check on that. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com
Received on Thursday, 6 March 2003 10:08:04 UTC