W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Simplifying CHECKOUT behavior for core versioning clients

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 2 Dec 2000 09:37:53 -0500 (EST)
Message-Id: <200012021437.JAA08275@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: "Boris Bokowski/OTT/OTI" <Boris_Bokowski@oti.com>

   > Currently, a core versioning client must check to see whether the
   > server supports version selector or version checkout, before it can
   > operate against a server.  This is because there are some servers that
   > only support "server side workspace" semantics for parallel
   > development (i.e. only support checking out a version selector), and
   > others only support "client side workspace" semantics for parallel
   > development (i.e. only support checking out a version).

   Note that both "server side private workspaces" and "client side workspace
   semantics" allow users to make changes that are not seen by other users.
   If core clients check out in place, their changes will be seen by other
   users. This is true even in the case of simple linear histories, so the
   following scenario would not be supported: update both contents and
   properties on a privately checked out resource, followed by a CHECKIN
   and a SET-TARGET which updates content and properties atomically for
   other users.

A client can effectively achieve the same effect by not doing the
PUT/PROPPATCH until it has changes it wants to make visible
and then locking the resource for the duration of the PUT/PROPPATCH.
The fact that there is a small window between the PUT and the PROPPATCH
during which another client could get the old properties and the new
content is not really an issue, because a client always has to get
the content and properties separately (GET/PROPFIND) so there always
is a window for such a skew (i.e. another client could do a PROPPATCH
between the GET and PROPFIND).

   > I believe we can address this issue by making branching an optional
   > feature (i.e. move it from core to optional).  Since "merging" is an
   > optional feature, and since branching is of limited value without
   > merging, it probably makes more sense make branch/merge a unified
   > optional feature, instead of the way it is now, where branch support
   > is required but merge support is optional.

   The MERGE method is optional, but a client can merge "by hand" using
   only core features (merging content and properties as appropriate,
   on a checked out resource, and then setting the DAV:predecessor-set
   property before the CHECKIN).

I agree.  My point about making branching optional is bogus anyway,
since branching is provided by the ability to do a SET-TARGET, not
by working resources or workspaces.  And the point is even more
bogus because branching is in fact useful without merging (as Greg
mentioned), so please forget I ever brought the point up (:-).

   > I am periodically asked why core versioning requires support for
   > parallel development when many useful versioning servers
   > (primarily for document management) only support linear versioning.
   > This is another motivation to make support for parallel development
   > optional.
   > 
   > If parallel development is not in core, then there is no need for
   > a resource to be checked out twice at the same time.

   I could agree on this, but what about the need for checking out a
   resource privately (see above)?

I believe that keeping authoring state on the client gives you most of
what clients want for this ... the only thing you lose is the ability
to create a version that *never* is visible to other clients under the
version selector URL.  This is a valid use case, but I believe it is
not nearly as important as the "don't make my changes visible until
I'm done" use case (which you can do in the new model).

Note that currently, a core client has to ask the server which form of
checkout the server supports, and then be prepared to either create
workspaces or keep track of working resources, depending on what the
server comes back with.  I predict that most clients will be designed
to work with one model or the other, which means most clients will not
benefit from saying that "a server must support one or the other".

But a core client will benefit from us instead saying a server "MUST
support in place checkout for version creation" and "MAY support
working resources or workspaces for hidden/parallel development".

   > This means that neither
   > workspaces nor working resources are required, and just the ability to
   > check-out and check-in a version selector is sufficient.  Note that a
   > server that is "working resource" based can easily implement this
   > behavior by associating a working resource with the version selector
   > while it is "checked out", and direct all operations on the version
   > selector to this working resource.

   On a "working resource" based server, version selectors would never
   be checked out, and it would always be possible to SET-TARGET them
   (or MERGE). This is no longer true in the model you propose.

This was never true for a core client, since the core protocol did not
require support for creating working resources.  So the new model only
adds things that a core client can count on, compared to the
existing model.

Cheers,
Geoff
Received on Saturday, 2 December 2000 09:38:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT