W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: UPDATE method and forking

From: Werner Donné <werner.donne@re.be>
Date: Thu, 16 Mar 2006 11:12:06 +0100
Message-ID: <441939F6.9000003@re.be>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org

Geoff,

I understand it can be done like that, but I have two remarks:

1) Such a scenario should in fact be one transaction. The proposed
   solution doesn't protect integrity. Currently the choice is not
   to expose transaction demarcation to the client. That implies
   the WebDAV model shouldn't expose scenarios which require transactions
   either.

2) The locking mechanism in a versioning system is not designed to
   implement transactional isolation. It is merely for long-duration
   reservations of versions.

I agree that workspaces are the feature for working in parallel, but
what is then the use of forking? Which problem does it solve?

Regards,

Werner.

Geoffrey M Clemm wrote:
> 
> If you don't want to use either workspaces or working resources,
> then you would just use the base WebDAV functionality for handling
> multiple clients concurrently updating the same resource, i.e. locking.
> 
> So in your original sequence, just wrap the sequence in an LOCK/UNLOCK
> pair, i.e.:  
> 
> LOCK the version-controlled resource
>> - Retrieve the current checked-in version. (PROPFIND)
>> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE)
>> - Perform a check-out or anything else that can be done on a version
>>   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
>> - Set the checked-in version back to what it was. (UPDATE)
> UNLOCK the version-controlled resource.
> 
> Cheers,
> Geoff
> 
> Werner wrote on 03/15/2006 08:31:46 AM:
>> I'm not referring to working resources and I know that normally
>> workspaces should be used to work in parallel. However, the
>> workspaces feature is optional and the checkout-in-place feature
>> doesn't depend on it. The checkout-in-place feature provides
>> forking and therefore the model should be consistent in the
>> absence of the workspaces feature.
>>
>> According to me forking and workspaces are unrelated. The forking
>> functionality stands on its own. When a fork is allowed for some
>> version, it may have more than one successor. The only way to
>> address a particular successor, for a check-out operation for example,
>> is by setting the checked-in version of the VCR to it. This is a
>> global state change.
> 
> 
>> Geoffrey M Clemm wrote:
>> >
>> > I believe you are confusing the "checkout-in-place" feature and
>> > the "working-resource" feature.  
>> >
>> > In the "checkout-in-place" feature, you make your changes
>> > directly on the VCR.  If two clients want to be working
>> > in parallel, they would have separate workspaces, and each
>> > client would have its own VCR, so the VCR is not shared global
>> > state, but rather is private state for the client that owns
>> > that workspace.
>> >
>> > In the "working-resource" feature, you do apply the
>> > CHECKOUT directly to a version (see section 9.3), so again,
>> > there is no mutable global state for which there would
>> > be contention.
>> >
>> > The only time in which there is shared mutable state is when
>> > two clients are sharing the same workspace.  In this case,
>> > the primary problem you face is the standard "lost update" problem
>> > while you are authoring the content, and the solution is the
>> > standard WebDAV solution: use the LOCK method.
>> >
>> > Cheers,
>> > Geoff
>> >
>> > Werner wrote on 03/15/2006 04:30:19 AM:
>> >>
>> >> The UPDATE method can be used to set the checked-in version of a
>> >> version controlled resource to a version which has descendants.
>> >> At that point a check-out may fork, resulting in the checked-in
>> >> version to have more than one descendant.
>> >>
>> >> This way a tree can be built. If one wants to grow the different
>> >> branches of such a tree, the UPDATE method should be used to set
>> >> the checked-in version of the version controlled resource
>> >> appropriately. This, however, changes global state, which could
>> >> lead to races.
>> >>
>> >> The complete operation the client would do is the following sequence:
>> >> - Retrieve the current checked-in version of the version controlled
>> > resource.
>> >> - Set it to the most recent version in a "branch".
>> >> - Perform a check-out or anything else that can be done on a version
>> >>   controlled resource.
>> >> - Set the checked-in version back to what it was.
>> >>
>> >> For this to work in a multi-user environment, either the sequence
>> >> should be executed atomically and in isolation, or methods such as
>> >> check-out should be allowed to operate on versions as well.
>>
>> --
>> Werner Donné  --  Re BVBA
>> Engelbeekstraat 8
>> B-3300 Tienen
>> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>>

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
Received on Thursday, 16 March 2006 10:12:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:14 GMT