W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Proposal: WebDAV and transactions

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Thu, 12 Sep 2002 12:24:03 -0700
To: <w3c-dist-auth@w3.org>

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:26:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC