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

Re: Proposal: WebDAV and transactions

From: Roy T. Fielding <fielding@apache.org>
Date: Wed, 11 Sep 2002 14:13:33 +0200
Cc: "Babich, Alan" <ABabich@filenet.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Message-Id: <E3F8C744-C57F-11D6-8502-000393753936@apache.org>

> I think it is clear that the best way to address this requirement is 
> through
> batching up WebDAV METHODS into a single request.  We also have 
> requirements
> for doing batch methods for other reasons, and I know Microsoft has also 
> run
> into this requirement and extended the standard this way.

I don't think that is clear at all.  Batching methods does nothing to
help with transactions that cannot be accomplished just as easily
(and without breaking HTTP security) by including a transaction identifier
in each request.  Changing the packaging of a sequence of interrelated
requests does not change the fact that they are a sequence of interrelated
requests.  Eventually, something has to process those requests in sequence,
as a transaction.  The server simply needs a way to accumulate requests
and a method to commit them, and therefore it makes sense to have methods
for begin-, abort-, and commit-transaction.

>> If the gun refuses to shoot you in the
>> foot, that is a better design for the gun.

In that case, a gun that is incapable of shooting at all would be
a "better" design.  Considering requirements in isolation is a waste
of energy.

>> In the spirit of that analogy, I
>> am proposing that the entire transaction, conditional processing and all,
>> should be invoked by one method call. That would do a lot to help protect
>> the performance of the system.

It would do nothing to help protect the performance of the system.
There is no effective difference between a sequence of requests with
time-outs per request and a batch request with time-outs per read.
The server still has to accumulate requests in storage and is
subject to the same service problems with stateful behavior.

The Web already has stored procedures.  There is nothing preventing an
application developer from building complex transactions within a
single method handler.  The problem is when you allow multiple methods
with differing semantics to take place under the rubric of another
method, which removes HTTP's ability to govern access rights per method.

Received on Wednesday, 11 September 2002 08:14:01 UTC

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