Re: UPDATE method and forking

Hi Manfred,

Manfred Baedke wrote:
> Hi Werner,
> 
>> You have two alternatives for working in parallel, where one suffices.
>> One
>> method, working resources, exposes physical aspects such as forking and
>> puts the resposibility for integrity at the client. The other is
>> abstract.
>> It doesn't expose implementation details, because each "branch" has its
>> own VCR and the checked-in version of each VCR can be left to be the most
>> recent version. The integrity responsibility is within the server.
>>   
> First of all, checking out a working resource _does_ create a new VCR,
> much like a VERSION-CONTROL request to an unmapped URL which is a member
> URL of a workspace, the main difference being that in the latter case
> the client can choose the URL. Both mechanisms can be used to create
> multiple VCRs sharing a common version history and both can (but not
> must) be used in the way you describe (letting the checked-in version of
> each VCR be the "end of a branch").

I have reread section 9 of RFC 3253 and I can't find prove of a VCR being
created for a working resource, but I'm misinterpreting something perhaps.

> I am still trying to understand what you mean when you speak of
> 'integrity'. Am I right that you propose, speaking loosely, that the
> 'original' VCR should belong to something like a 'main branch', its
> checked-in version always being the end of that branch, and that a new
> branch should be created by creating a new VCR (based on an 'old
> version') within a workspace?

Indeed, that is correct. With integrity I mean making sure that the
system is always in a consistent and predictable state. This is
normally achieved with transactions. Workspaces, being more abstract,
provide the opportunity for an "advanced" implementation to offer
such a guarantee. At the same time a less advanced implementation that
is deployed in a stand-alone environment, i.e. without concurrency
and the risk for races, can also comply to the workspaces specification.

Since the UPDATE method can change the checked-in version of a VCR
globally, the result may be unpredictable. (It will probably be
consistent, however, because the UPDATE method itself is normally
atomic.) This is because client may "forget" to use locking. If two
such clients are working concurrently on the same VCR, the checked-in
version may change in the middle of their scenario. They may end up
checking out from some other version without realising it. You can blame
those clients rightfully for it, but when there is a central system
it must make sure itself that this can't happen. The central system
can't rely on all clients to behave correctly.

Contrarily to what the spec suggests, I think it is simpler for both
client AND server if only workspaces are supported for working in
parallel.

> I you do so, feel free not to support the UPDATE feature in your
> implementation.

That is indeed possible, but I still would like to know where this
UPDATE and forking comes from and what purpose it serves. Turning it
the other way around, which problems would arise if it was left out?

> 
> Regards,
> Manfred

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 17 March 2006 15:25:00 UTC