- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 13 Sep 2002 17:48:52 -0400
- To: w3c-dist-auth@w3.org
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