RE: Proposal: WebDAV and transactions - optional versioning usage

In a stateless protocol, such as HTTP, something special needs to be
done to tell the server what transaction the operation is to be
applied to.  Since the automatic addition of a header can be done in a
way that is effectively invisible to a client, that is one approach to
consider.  In particular, this was considered seriously for (and for a
while, part of) DeltaV, but was finally rejected because it introduces
unacceptable complexities in various advanced use cases (such as
cross-transaction queries, which DeltaV allows).

Instead, in the DeltaV model, with workspace transactioning,
you prefix each URL with the name of the workspace that identifies
the transaction.  Alternatively, with working resource transactioning,
the server gives you a separate URL for each resource you want to
modify as part of the transaction.

If we find that the workspace or working resource transactioning model
is not sufficiently invisible to a client, we could always consider
reintroducing the "Workspace" header, for transactioning usage of
DeltaV.

Cheers,
Geoff


   From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]

   It is unclear to me how this would accomplish transaction support
   in the usual way.

   The appeal of bracketed transaction management is that the client
   does nothing appreciable between the brackets that would not be
   done in a conventional, exclusive-use-of-repository model.  At
   successful commit, it is literaly as if nothing different had
   occurred.  And if a client aborts a transaction, there is no
   operation required on the part of the client to "undo" all of the
   transaction-protected operations.

   So I don't think there is an "invisible" case by use of a facility that
   appears to honor transactioning methods yet doesn't provide support for
   transactioning.

   Assuming, of course, that we are talking about something like
   full-capability transaction processing integration.

   -----Original Message-----
   From: Clemm, Geoff

   If a client is interacting with a versioning server, then
   yes, the history (including the activity info) would be
   saved, but if they are interacting with a non-versioning
   server, they would lose the history (of both versions
   and activities/transactions), but a client would be able to
   use the same protocol in each case, making life easier for
   a client writer.  This is very similar to auto-versioning
   with locks ... a locking client just thinks it is creating
   and deleting locks, but if it is doing so against a versioning
   server, history will be kept.  And just as an "unlock" is
   a reasonable clue that "this information is worth saving in
   the history", a "commit" is even a stronger clue.

   And it would be easy for a client to find out if it is
   interacting with a "versioning" deltav server, by checking
   if the "version history" report is available.

Received on Friday, 13 September 2002 17:49:24 UTC