RE: Interest in standardizing Batch methods?

Matt,

I think this is definitively going to be too ambitious.

We really should start collecting the requirements first (as Jim did).

If the problem you're trying to solve is an update of a structured
(multivalued) property, you could do this by LOCKing the resource now.

A lightweight protocol that doesn't need LOCKs could be defines like:

- define a "PTag" (comparable to the ETag) that changes when properties
change,
- extend the request body to PROPPATCH to optionally include the PTag you
have and  only do the PROPPATCH if the PTag is still valid)
- alternatively, extend DAV:set to marshall a reference value to which the
current value is compared before updating the property.

For instance:

<conditional-set xmlns="DAV:">
  <old>oldvalue</old>
  <new>newvalue</new>
</conditional>

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Matt Timmermans
> Sent: Wednesday, January 09, 2002 5:59 PM
> To: 'Pill, Juergen'; 'WebDAV'
> Subject: RE: Interest in standardizing Batch methods?
>
>
> > -----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 12:34:56 UTC