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

RE: Interest in standardizing Batch methods?

From: Matt Timmermans <mtimmerm@opentext.com>
Date: Wed, 9 Jan 2002 11:58:46 -0500
To: "'Pill, Juergen'" <Juergen.Pill@softwareag.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <001a01c1992e$e7b1f770$d482a8c0@mt2k>
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> [...]
> I want to suggest instead of introducing a series of Bxxx methods, to
> introduce only a single method named BATCH, which caries a
> series of WebDAV
> methods within his XML body. This would allow to execute a
> scenario within a
> transaction (e.g. lock, put, proppatch, unlock). Multiple
> delete methods
> would be covered by this approach too.
> [...]
> This BATCH method would open the door into a BATCH language,
> e.g. execute
> request #2 only if request #1 results in a 200/OK response code.

This is very powerful if you do it properly.  The lack of any transaction
control in WebDAV currently makes it impossible to perform many operations
safely.  If a document has a property that lists its contributing authors,
for example, you can't add a name to that list unless you know that noone
else will be doing the same thing concurrently.

Obviously, you can't allow clients to separately start and stop
transactions, so you have to get them to send the whole transaction in a
batch.  The batch must express the semantics of the transaction, so it's
tempting to include a Turing complete batch language.  That is evil, though,
because then a batch may consume unbounded resources.

I've looked into this somewhat, however, and determined the minimum
functionality required by the batch language to allow any arbitrary
operation to be performed by the client safely.  The minimal requirements
are:

1) any request that can be performed outside of a batch can be sent inside a
batch; and

2) the batch can be aborted if any queried persistent state does not match
some given, expected value.

3) the client is informed when a batch is aborted because of condition (2).

To perform a safe update to the contributors list, for example, a client can
do this:

1) PROPFIND to get the list of contributors (oldlist)

2) BATCH:
PROPFIND to get the list of contributors (oldlist')
ABORT if oldlist' != oldlist
PROPPATCH contributors = oldlist+newname

3) If batch aborted due to the condition, go back to step 1.
Received on Wednesday, 9 January 2002 11:59:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT