- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sun, 9 Mar 2003 09:18:45 -0800
- To: "'Jason Crawford'" <nn683849@smallcue.com>
- Cc: <acl@webdav.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'WebDAV'" <w3c-dist-auth@w3.org>
> > But back to the atomic vs. non-atomic move, the permissions > example was > > just an example. You still have to recursively check > privileges on all > > descendent _collections_ if one accepts your permissions > model. And you > > still have to recursively check locks, etc. The basic argument for > > non-atomic move was that in some situations, the server will have to > > implement it as a super-user COPY-->DELETE. > > Again... even in situations where it has to implement it under the > covers as a DELETE(dest)/COPY/DELETE(src), it can still be > atomic or nearly so because it can be backed out up to and including > the atomic remap. After that it's committed and the WebDAV MOVE's > response's > status code is not sensitive to how the subsequent cleanup goes. OK, now we're getting to pinpoint our different assumptions. Do you assume it's better for the server to do the atomic remap, return "success", and worry about cleanup later? That's valid for some servers, certainly. If there are "orphaned" resources, the administrator can clean them up later. However, that assumption isn't valid for all servers. For a server like Sharemation, we count each file stored against some user's quota. If a collection MOVE or DELETE fails, and we can't free up that quota, we need to let the user know so they can fix it up. It's quite possible the user will be able to fix up the operation by removing locks, getting permissions changed, or simply trying again. Finally, the server needs to consider if rollback is feasible or desirable. In theory, it would be reasonable to say that servers SHOULD succeed 100%, or failing that SHOULD rollback 100%, or only if both those fail should the server report a partial success. That's not the model WebDAV has had so far, however. So that might be a reasonable position for the bindings specification to take but I'm not sure people would support changing RFC2518 in that manner. Lisa
Received on Sunday, 9 March 2003 12:18:48 UTC