Subject: RE: Proposal: WebDAV and transactions

From: Gary Cowan <[email-masked]>
Date: Thu, 12 Sep 2002 15:20:55 -0400

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:[email-masked]]
Sent: Thursday, September 12, 2002 3:11 PM
To: 'Roy T. Fielding'; [email-masked]
Subject: RE: Proposal: WebDAV and transactions

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]] 
Sent: Thursday, September 12, 2002 7:01 AM
To: Babich, Alan
Cc: [email-masked]
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

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 12 Sep 2002 12:24:03 -0700

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 12 Sep 2002 21:41:20 +0200

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Thursday, September 12, 2002 9:24 PM
> To: [email-masked]

That's an excellent example for a case where a LOCK (or a delta-V working
resource) is all you need, right?

It get's more interesting once you want to manipulate *several* related
resources.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Elias Sinderson <[email-masked]>
Date: Thu, 12 Sep 2002 14:00:42 -0700

Updating multiple, mutually-dependant resources (related portions of a 
web site, for example) is a reasonable use case that would benefit from 
transactions.

Elias