RE: Proposal: WebDAV and transactions

Just to be clear here, I wasn't suggesting that we actually use the
DeltaV protocol as a WebDAV transaction protocol.  You need different
versioning and transactioning methods for a server that supports both
versioning and transactions, so that a client can say whether it wants
versioning behavior or transactioning behavior.

I was just making the point that a repository that supported
transactions (but not versioning) could sensibly interact with a
DeltaV client by defining transaction boundaries on certain DeltaV
constructs.  Conversely, depending on how the transactioning
protocol is defined, a repository that supported versioning
(but not transactions) might be able to sensibly interoperate
with a transactioning client by mapping the transactioning
requests into server-side workspace functionality.

Cheers,
Geoff

-----Original Message-----
From: Zaretzke, Peter [mailto:Peter.Zaretzke@softwareag.com]
Sent: Monday, September 16, 2002 7:54 AM
To: 'w3c-dist-auth@w3.org'
Subject: 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) where transaction control is planned
to be part of Level 2. 
Any comments?

Received on Monday, 16 September 2002 09:58:57 UTC