- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 12 Sep 2002 23:54:16 -0400
- To: w3c-dist-auth@w3.org
I don't think I see your point. If a client is interacting with a versioning server, then yes, the history (including the activity info) would be saved, but if they are interacting with a non-versioning server, they would lose the history (of both versions and activities/transactions), but a client would be able to use the same protocol in each case, making life easier for a client writer. This is very similar to auto-versioning with locks ... a locking client just thinks it is creating and deleting locks, but if it is doing so against a versioning server, history will be kept. And just as an "unlock" is a reasonable clue that "this information is worth saving in the history", a "commit" is even a stronger clue. And it would be easy for a client to find out if it is interacting with a "versioning" deltav server, by checking if the "version history" report is available. Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Thursday, September 12, 2002 10:06 PM To: Clemm, Geoff; w3c-dist-auth@w3.org Subject: Re: Proposal: WebDAV and transactions This would be ok as long as it is cheap to delete activities on your server. I suspect this solution wouldn't perform because of the other expectations folks have of activities (intermediate state is persistent, for example). --Eric ----- Original Message ----- From: "Clemm, Geoff" <gclemm@rational.com> To: <w3c-dist-auth@w3.org> Sent: Thursday, September 12, 2002 1:20 PM Subject: RE: Proposal: WebDAV and transactions > > The Lock/Unlock doesn't give you the "rollback" functionality > (i.e. the client has to remember the old values, and live long > enough to restore them if the later updates fail). > > But it would be interesting to investigate whether the > DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most > of the benefits of transactions (a non-versioning server would > only keep the most recently checked in "version" of a resource). > You would create an "activity" for a given transaction, > make your changes, and then CHECKIN the activity to commit > all the changes, or UNCHECKOUT to roll them back. > > Cheers, > Geoff > > -----Original Message----- > From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com] > Sent: Thursday, September 12, 2002 3:43 PM > To: 'Jim Whitehead'; w3c-dist-auth@w3.org > Subject: RE: Proposal: WebDAV and transactions > > > > 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 23:54:49 UTC