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 Thursday, 12 September 2002 23:54:49 UTC