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 Julian Reschke
>
> Matt,
>
> I think this is definitively going to be too ambitious.

Possibly, but I believe it's the simplest and least dangerous solution that
allows you to perform arbitrary compound operations with ACID semantics.

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

Personally, I think it should be a requirement that you can perform
arbitrary operations with ACID semantics.  If you can't, then WebDAV is
unsafe for many applications.  The problem is that it can still be, and will
be, used for those applications.

But, of course, if noone else feels that way, then it's not a requirement,
and we needn't worry about it.

> 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.

That was the example, but there are an infinite variety of others that
aren't restricted to a single resource, or just to properties.

Most of these cannot be done with locking.

> 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.
>

Both of these only work for operations on a single resource, and the PTag
can be very expensive to calculate.

It probably is overkill to support a full execute-and-compare-results, but
you can get the same functionality (for WebDAV) with a simple ASSERT method
that only needs to be able to perform a few simple checks -- to confirm that
a given property on a given resource has a given value, to confirm that a
given resource exists or not, to confirm that an entity body hasn't changed
(using etag if available), and to confirm the OPTIONS response of a given
resource.

If we're going to do transactional BATCH, then this is a very small price to
pay to get real transactional semantics.

Received on Wednesday, 9 January 2002 13:43:23 UTC