- From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
- Date: Thu, 12 Sep 2002 15:42:40 -0400
- To: "'Jim Whitehead'" <ejw@cse.ucsc.edu>, w3c-dist-auth@w3.org
Well I suppose, but isn't this what wrapping updates with a Lock/Unlock pair is intended to accomplish. I have nothing against transactions, I just don't have any need for them spanning multiple WebDAV methods. Yet:) -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Thursday, September 12, 2002 3:24 PM To: w3c-dist-auth@w3.org Subject: RE: Proposal: WebDAV and transactions One common example is to be able to write a resource and its properties in a single operation. You want this to be a transaction, so that the resource doesn't get updates before the properties are written, and so that if the properties cannot be written, the resource is reverted back to it's pre-write state. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan > Sent: Thursday, September 12, 2002 12:21 PM > To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org > Subject: RE: Proposal: WebDAV and transactions > > > > At the risk of sounding naive, I cannot understand why anyone > would want or > need transactions in a WebDAV session. > > -----Original Message----- > From: Babich, Alan [mailto:ABabich@filenet.com] > Sent: Thursday, September 12, 2002 3:11 PM > To: 'Roy T. Fielding'; w3c-dist-auth@w3.org > Subject: RE: Proposal: WebDAV and transactions > > > > > > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Thursday, September 12, 2002 7:01 AM > To: Babich, Alan > Cc: w3c-dist-auth@w3.org > Subject: Re: Proposal: WebDAV and transactions > > ...snip... > > <Alan> > > Between the method calls, the resources changed have to be locked on the > > server. > </Alan> > > <Roy> > That's not how I described transactions. I said that the requests are > collected on the server and only applied when the commit message is > received. If the state has changed such that the methods are no longer > applicable, then the method transaction will fail on commit. > </Roy> > > That directly addresses the central issue, and I managed to miss that > somehow. >>My whole point is that when the server actually executes the > transaction, the server should have everything and do the entire > transaction > all at once -- retrievals, updates, and conditional processing included.<< > Sorry if I didn't make that clear. > > If you want to dribble the instructions for the transaction over piece by > piece by making separate method calls until it all gets to the server, > without actually doing any updates or retrievals, that's not > something that > I am concerned with much. It would be more efficient to just send over all > the stuff at once, but I don't think it's that big of a deal to > send it over > in pieces. So, doing that is OK with me. > > If you want the server to do some security checking and other > processing on > the individual pieces as they arrive, before actually executing the entire > transaction in the commit step, that's fine. That would help the client > pinpoint a certain subset of the possible problems in each step of the > transaction. > > --- > > I think it would be interesting to see how the conditional > processing of the > methods is specified. How much generality is achievable without > getting into > syntax that doesn't resemble the current methods at all? To make arbitrary > transactions convenient, you want "program" variables, conditional > "statements", iteration "statements", and "subroutines" with > parameters. If > we don't go that far, perhaps a useful set of transactions could still be > specified. > > I also think it would be interesting to see how the results of the > transaction are specified. Any part of it could fail. > > Alan
Received on Thursday, 12 September 2002 15:43:18 UTC