RE: Proposal: WebDAV and transactions

Some thoughts regarding the question "Who needs transactions with WebDAV?"

For me the major benefit of being able to control a transaction is
CONSISTENCY (and convenience). Keeping track of multiple dependent
modifications on WebDAV resources can become hard for a client and is
usually not what a application programmer wants to do. He wants to define
his "transaction" spanning multiple (WebDAV) calls and depending on the
return codes or his user decision he wants to commit or rollback
(all-or-nothing). Millions of SQL applications are working this way and I
can't see what is wrong with it.  

Batch processing does not really help here since some applications rely on
that intermediate modifications are available at the server, e.g. for query
purposes. Collecting modifications on the client would make query processing
far more complex since the server result has to be combined with the client
side modified resources. Additionally I would like to have the ability to
react on the return codes for single calls. BTW: processing a batch request
requires transactions on the server anyway (all-or-nothing), otherwise it
would be possible to create inconsistencies if the 3rd of 5 dependent PUTs
fails.  

Another aspect is working ISOLATION. Workspaces and activities are helpful
here. But creating something like a transaction with it, means programming
it on the client. Why should somebody re-invent the "transaction logging
wheel" in his application? Will somebody accept to go back to file-based
application programming style (without transactions) if he is familiar with
SQL database programming? 

For me it does not matter if the COMMIT, ROLLBACK methods are part of the
WebDAV protocol. If there is already a protocol that covers this - great,
let's take it and make it a (optional?) WebDAV extension like DASL or ACL.
But I definitely need server transactions to write complex WebDAV
applications without too complex coding. 

I see a WebDAV server as a Resource Manager like any database with nice
extensions like versioning, configuration management, etc. In my opinion a
successful general-purpose WebDAV server has to cover the common RM
features. I'm currently working on a Content Repository API on top of a
WebDAV server, which is intended to become compliant to JSR170
(http://www.jcp.org/jsr/detail/170.jsp
<http://www.jcp.org/jsr/detail/170.jsp> ) where transaction control is
planned to be part of Level 2. 

Any comments?

Peter
-------------------
Peter Zaretzke
Software AG