Re: UPDATE method and forking

Werner Donné <werner.donne@re.be> wrote on 03/17/2006 10:25:00 AM:
> Manfred Baedke wrote:
> > 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.

Manfred's description isn't quite right ... you don't check out a working
resource ... you create a working resource by checking out a version.
You then update the working resource (with PUT) and check it in, which
deletes the working resource and creates a new version.  So Werner is 
correct
that there are two distinct ways of working.
The workspace way:
- you apply CHECKOUT to a VCR, which makes the VCR writeable
- you update the VCR with PUT
- you apply CHECKIN to the VCR, which creates a new version and makes the 
VCR
  unwriteable.
The working resource way:
- you apply CHECKOUT to a version, which creates a new working resource
- you update the working resource with PUT
- you apply CHECKIN to the working resource, which creates a new version 
and
  deletes the working resource.

> > 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.

Or with the working resource model, the state of the transaction is
basically the set of working resources currently held by the client.
Those working resources are effectively private to that client, and
therefore no other client can interfere with the transaction.  Much
lower level than workspaces, more work/complexity for the client, but much 
lower
overhead on the server.

> 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.

Yes, the workspace model is the simple/clean way to achieve this.
The locking model is the "works with existing clients" approach.

> 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.

The working resource model is worse for the client than the workspace
model, but is significantly better than locking and a scalable
working resource server is significantly easier to implement than
a scalable workspace server.

> > 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?

If your server does not support workspaces, then the only real benefit
of UPDATE is that it allows you to avoid creating a new version when
a client wants to restore an old version.  In particular,
if you don't support UPDATE, then the only way that your client can
tell the server that it wants to change the state back to that of some
previous version is to GET the content of the desired version,
CHECKOUT the VCR, PUT the content it got, and then CHECKIN, which creates
a new version (which is a copy of an existing version).  With UPDATE,
you can just send an UPDATE request to the server, with the URL of the
desired version (which both avoids creating a new version, and avoids
streaming the content back to the client via GET and then back to the
server via PUT).

Cheers,
Geoff