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

Re: UPDATE method and forking

From: Manfred Baedke <manfred.baedke@greenbytes.de>
Date: Fri, 17 Mar 2006 15:57:12 +0100
Message-ID: <441ACE48.3010305@greenbytes.de>
To: werner.donne@re.be
CC: w3c-dist-auth@w3.org, geoffrey.clemm@us.ibm.com

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 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?
I you do so, feel free not to support the UPDATE feature in your 
implementation.

Regards,
Manfred
Received on Friday, 17 March 2006 14:57:16 GMT

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