- From: B. Shadgar <shadgar@cs.bris.ac.uk>
- Date: Mon, 02 Sep 2002 12:35:15 +0100
- To: "Pill, Juergen" <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
"Pill, Juergen" wrote: > Hello, > > The current WebDAV specifications deal with a transactional support on a > method base only. Either a single WebDAV method is completely and > successfully executed, or the method is not executed at all (e.g. a > PropPatch command will either modify all requested properties or none of > them). A transactional support spanning multiple WebDAV methods is currently > not specified. > Multi user requirements are either handled in separate workspaces (Delta-V) > or via the Lock method. > During our discussion on the JSR 170 (Content Management API) implementation > on top of WebDAV, we believe that we require longer transactions spanning > multiple separate WebDAV methods. (This issue was already partially > discussed in the Batch method thread). Do you also fell the need/requirement > to get a standard on the way, concerning a transactional WebDAV protocol > extension? > > A possible use case would be: > An author wants to modify an html page. To successfully do so, he will PUT > the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap > files, which are not references any more, and PUT (create) the newly > referenced bitmaps files. If he wants to ensure, that either all his changes > do apply (or none of them) he would surround those method call with an > TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g. > JSR 170) exposing the TA functionality to an application, we believe this > feature to be mandatory. > > A possible (starting) specification could be: > WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The > TA-BEGIN method will return a TA token (e.g. via an XML response body). This > TA token will be send to the following WebDAV methods, which are part of > this transaction (e.g. via an additional header). The TA-COMMIT or TA-ABORT > method will either commit or abort the transaction and invalidate the TA > token. > If and when an open TA, which is not used any more, is aborted, could be > controlled similar to the lock method timeout header. > All WebDAV methods, which either do not posses a TA token, or posses an > invalid token are handled as today (the method is executed within its own > TA), this would ensure upward compatibility. > This extension would be optional, if a server supports the TA methods, it > will state this in the OPTIONS request (similar to Delta-V). > > Does this make sense? > > Best regards > Juergen Pill Juergen, It is what exactly I was thinking about. I've got another scenario of possible using TA- methods you have proposed. I need those transaction methods since I am dealing with accessing the database through the web based on the WebDAV protocol. In other words, I've almost prepared an application which accesses to the database and considers the database data model as WebDAV resources. With all methods are provided by WebDAV and other WG + Batch method , I am able to send almost all SQL queries into the server in form of WebDAV methods. But some statements like commit, rollback, savepoint can not be implemented by WebDAV methods, and it is exactly what you suggesting; TA-COMMIT, TA-ABORT and TA-BEGIN. This application can be another possible use case of those three methods + Batch method which is discussed already but hasn't been accepted as a WebDAV method. If I want to complete your proposal from my point of view I would say: Since the WebDAV claims to encompass all kind of web resources representing by URI, databases resource can be considered as its resource and therefore to support database operation we would need TA- Methods as well as Batch Method. Regards, Bita
Received on Monday, 2 September 2002 07:36:02 UTC