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 15:43:18 UTC