RE: Proposal: WebDAV and transactions - optional versioning usage

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.

-- Dennis

Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:dennis.hamilton@acm.org  tel. +1-206-932-6970
http://DMware.info/             cel. +1-206-779-9430
     ODMA Support http://ODMA.info/

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Thursday, September 12, 2002 20:54
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



I don't think I see your point.

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.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Thursday, September 12, 2002 10:06 PM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions


This would be ok as long as it is cheap to delete activities on your server.
I suspect this solution wouldn't perform because of the other expectations
folks have of activities (intermediate state is persistent, for example).

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, September 12, 2002 1:20 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The Lock/Unlock doesn't give you the "rollback" functionality
> (i.e. the client has to remember the old values, and live long
> enough to restore them if the later updates fail).
>
> But it would be interesting to investigate whether the
> DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
> of the benefits of transactions (a non-versioning server would
> only keep the most recently checked in "version" of a resource).
> You would create an "activity" for a given transaction,
> make your changes, and then CHECKIN the activity to commit
> all the changes, or UNCHECKOUT to roll them back.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
> Sent: Thursday, September 12, 2002 3:43 PM
> To: 'Jim Whitehead'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Well I suppose, but isn't this what wrapping updates with a Lock/Unlock
pair
> is intended to accomplish. I have nothing against transactions, I just
don't
> have any need for them spanning multiple WebDAV methods. Yet:)
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, September 12, 2002 3:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its properties in
a
> single operation. You want this to be a transaction, so that the resource
> doesn't get updates before the properties are written, and so that if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.
>
> - Jim
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> > Sent: Thursday, September 12, 2002 12:21 PM
> > To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > At the risk of sounding naive, I cannot understand why anyone
> > would want or
> > need transactions in a WebDAV session.
> >
> > -----Original Message-----
> > From: Babich, Alan [mailto:ABabich@filenet.com]
> > Sent: Thursday, September 12, 2002 3:11 PM
> > To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Roy T. Fielding [mailto:fielding@apache.org]
> > Sent: Thursday, September 12, 2002 7:01 AM
> > To: Babich, Alan
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...snip...
> >
> > <Alan>
> > > Between the method calls, the resources changed have to be locked on
the
> > > server.
> > </Alan>
> >
> > <Roy>
> > That's not how I described transactions.  I said that the requests are
> > collected on the server and only applied when the commit message is
> > received.  If the state has changed such that the methods are no longer
> > applicable, then the method transaction will fail on commit.
> > </Roy>
> >
> > That directly addresses the central issue, and I managed to miss that
> > somehow. >>My whole point is that when the server actually executes the
> > transaction, the server should have everything and do the entire
> > transaction
> > all at once -- retrievals, updates, and conditional processing
included.<<
> > Sorry if I didn't make that clear.
> >
> > If you want to dribble the instructions for the transaction over piece
by
> > piece by making separate method calls until it all gets to the server,
> > without actually doing any updates or retrievals, that's not
> > something that
> > I am concerned with much. It would be more efficient to just send over
all
> > the stuff at once, but I don't think it's that big of a deal to
> > send it over
> > in pieces. So, doing that is OK with me.
> >
> > If you want the server to do some security checking and other
> > processing on
> > the individual pieces as they arrive, before actually executing the
entire
> > transaction in the commit step, that's fine. That would help the client
> > pinpoint a certain subset of the possible problems in each step of the
> > transaction.
> >
> >                                  ---
> >
> > I think it would be interesting to see how the conditional
> > processing of the
> > methods is specified. How much generality is achievable without
> > getting into
> > syntax that doesn't resemble the current methods at all? To make
arbitrary
> > transactions convenient, you want "program" variables, conditional
> > "statements", iteration "statements", and "subroutines" with
> > parameters. If
> > we don't go that far, perhaps a useful set of transactions could still
be
> > specified.
> >
> > I also think it would be interesting to see how the results of the
> > transaction are specified. Any part of it could fail.
> >
> > Alan
>
>

Received on Friday, 13 September 2002 11:32:21 UTC