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

Proposal: WebDAV and transactions

From: Pill, Juergen <Juergen.Pill@softwareag.com>
Date: Mon, 2 Sep 2002 12:24:17 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2AC2@daemsg02.software-ag.de>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>

Hello,

The current WebDAV specifications deal with a transactional support on a
method base only. Either a single WebDAV method is completely and
successfully executed, or the method is not executed at all (e.g. a
PropPatch command will either modify all requested properties or none of
them). A transactional support spanning multiple WebDAV methods is currently
not specified.
Multi user requirements are either handled in separate workspaces (Delta-V)
or via the Lock method.
During our discussion on the JSR 170 (Content Management API) implementation
on top of WebDAV, we believe that we require longer transactions spanning
multiple separate WebDAV methods. (This issue was already partially
discussed in the Batch method thread). Do you also fell the need/requirement
to get a standard on the way, concerning a transactional WebDAV protocol
extension?

A possible use case would be:
An author wants to modify an html page. To successfully do so, he will PUT
the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
files, which are not references any more, and PUT (create) the newly
referenced bitmaps files. If he wants to ensure, that either all his changes
do apply (or none of them) he would surround those method call with an
TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
JSR 170) exposing the TA functionality to an application, we believe this
feature to be mandatory.

A possible (starting) specification could be:
WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
TA-BEGIN method will return a TA token (e.g. via an XML response body). This
TA token will be send to the following WebDAV methods, which are part of
this transaction (e.g. via an additional header). The TA-COMMIT or TA-ABORT
method will either commit or abort the transaction and invalidate the TA
token. 
If and when an open TA, which is not used any more, is aborted, could be
controlled similar to the lock method timeout header.
All WebDAV methods, which either do not posses a TA token, or posses an
invalid token are handled as today (the method is executed within its own
TA), this would ensure upward compatibility.
This extension would be optional, if a server supports the TA methods, it
will state this in the OPTIONS request (similar to Delta-V).


Does this make sense?

Best regards
Juergen Pill
Received on Monday, 2 September 2002 06:24:19 GMT

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