- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Tue, 10 Sep 2002 00:51:57 -0700
- To: "Babich, Alan" <ABabich@filenet.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
I think it is clear that the best way to address this requirement is through batching up WebDAV METHODS into a single request. We also have requirements for doing batch methods for other reasons, and I know Microsoft has also run into this requirement and extended the standard this way. --Eric ----- Original Message ----- From: "Babich, Alan" <ABabich@filenet.com> To: "'Julian Reschke'" <julian.reschke@gmx.de>; "Pill, Juergen" <Juergen.Pill@softwareag.com>; <w3c-dist-auth@w3.org> Sent: Monday, September 09, 2002 12:36 PM Subject: RE: Proposal: WebDAV and transactions > > The database vendors faced the issue of transactions in a client-server > network when they distributed their databases some ago. The naïve approach > of just remoting each database call was a performance disaster on large > networks. That is why they invented database script programming languages > and stored procedures. Stored procedures are scripts (in a database > programming language) that allow fairly general database transactions to be > programmed. These scripts are stored in the database. Clients invoke the > scripts by passing them parameters. > > Besides performance, one of the advantages of stored procedures is > standardization of the database processing. The system doesn't have to > depend upon every client getting the update processing correct. The stored > procedures can theoretically enforce all the checking and standardization > required. If one limits who can write stored procedures to a small trusted > group, the integrity of the system is protected. > > As you pointed out, it is sometimes the case that the processing involved in > WebDAV transactions as you envision them is conditional on the result of > previous processing steps. > > If you give people a gun they can shoot themselves in the foot with, then a > certain percentage of the people will shoot themselves in the foot. (I know > someone who literally did that.) If the gun refuses to shoot you in the > foot, that is a better design for the gun. In the spirit of that analogy, I > am proposing that the entire transaction, conditional processing and all, > should be invoked by one method call. That would do a lot to help protect > the performance of the system. > > Within the single-method constraint, there are two ways to go: (1) Specify > the entire transaction, conditional processing and all, within the stuff you > send over the network in the method invocation. (2) Invent stored WebDAV > procedures that specify WebDAV transactions (conditional processing and > all), and have the method pass parameters to the stored procedure. You could > think about taking either or both of these approaches. > > It is an open question as to whether either of the above two approaches can > be done well without doing violence to HTTP and/or WebDAV. > > Alan > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, September 09, 2002 7:34 AM > To: Pill, Juergen; w3c-dist-auth@w3.org > Subject: RE: Proposal: WebDAV and transactions > > > Jürgen, > > I think the main issue isn't that people aren't interested -- it's more that > they (well, I) think that it's an extremely bad idea that doesn't adher to > the HTTP model. > > In particular, it would make the meaning of an HTTP method invocation depend > on previous method calls. That makes it hard or impossible for > intermediaries to work with these messages. > > Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen > > Sent: Monday, September 09, 2002 4:17 PM > > To: 'w3c-dist-auth@w3.org' > > Subject: RE: Proposal: WebDAV and transactions > > > > > > > > Hello, > > > > I did not receive a lot of feed-back on the TA "proposal" (and the > > statements were both positive and negative). > > > > Would you agree on the statement, the WebDAV group would be currently not > > interested in standardizing TA methods? > > > > As we would need this extension for the API implementation, our > > option would > > be to implement a proprietary WebDAV TA extension available on our server > > only. > > > > If the interest on this topic would raise again - possibly at a > > later time - > > we would be happy to share our experience with you. > > > > Best regards, > > > > Juergen Pill > > > > > > > > -----Original Message----- > > From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com] > > Sent: Monday, September 02, 2002 12.24 PM > > To: 'w3c-dist-auth@w3.org' > > Subject: Proposal: WebDAV and transactions > > > > > > 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 > > > >
Received on Wednesday, 11 September 2002 02:02:28 UTC