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

Re: why workspaces

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 12 Oct 2000 11:33:34 -0400 (EDT)
Message-Id: <200010121533.LAA20286@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   Well... as a counterpoint argument: I've never viewed workspaces as a
   central concept. I've always found them rather bothersome. That darned
   Workspace header just felt a bit wrong to me. Thankfully, I could implement
   a lot of DeltaV and just completely disregard the workspace concept.

You are maintaining a copy of the versioned resource tree (sometimes
called a "sandbox") on your client I assume, for local builds,
disconnected use, etc. ?

Now what if you wanted to represent that sandbox on the server?
That's what a workspace is.

Here's some additional motivation I'll be adding to the "Workspace"
section of the protocol:

It is often desirable to allow several clients on behalf of a single
user to access a related set of checked-out resources.  In particular,
this allows a user to access these resources from several physical
locations, such as from another office, from home, from a remote site,
or while traveling, without being forced to prematurely checkin those
checked-out resources.  Sometimes it is even desirable to provide
shared access to checked-out resources for several closely cooperating
users (using WebDAV locking to avoid overwrite problems).

If only one set of checked-out resources is required, then this can be
achieved with core versioning by simply checking out the appropriate
version selectors.  This approach is often unacceptable because it
exposes the intermediate states of the checked-out resources to every
client, and does not allow for a second set of checked-out resources
to be defined for a group that wishes to be isolated from the
intermediate states of another group.  Unfortunately, working
resources do not address this problem, because although they allow
multiple concurrent checkouts from a single version history, there is
no mechanism for grouping related working resources into an
identifiable set.

A related problem is that it is often desirable to isolate clients
from a logical change that involves renaming shared resources, until
that logical change is complete and tested.  When all clients use a
common set of shared version selectors, every client sees the result
of a MOVE as soon as it occurs.

An additional problem is that it is often necessary to perform testing
on the server rather than on the client.  Since a test routine on the
server has no way of knowing what working resources or what versions
are to be tested, only the versions selected as the current target of
the version selectors can be tested.  This not only does not allow
testing of a checked-out resource before checking it in, but also does
not provide for any parallel testing of different configurations of
versioned resources.

To address these problems, advanced versioning introduces the concept
of a "workspace".  A workspace is a collection whose members are a set
of related version selectors and unversioned resources.  In order to
expose multiple views of a set of related version selectors in the URL
namespace, multiple workspaces may be used.  In order to make a change
made to a version selector in one workspace visible in another
workspace, that version selector must be checked in, and then the
corresponding version selector in the other workspace can be updated
to display the content and dead properties of the new version.  In
order to ensure unambiguous merging and baselining semantics, a
workspace may contain at most one version selector for a given version
history (although a server may support multiple bindings in a
workspace to the same version selector).


Received on Thursday, 12 October 2000 11:34:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC