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 []
Sent: Thursday, September 12, 2002 3:24 PM
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:
> []On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding';
> 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 []
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding';
> Subject: RE: Proposal: WebDAV and transactions
> -----Original Message-----
> From: Roy T. Fielding []
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc:
> 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