Re: WeDAV Versioning Summary

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sat, 8 May 1999 15:24:34 -0400 

Date: Sat, 8 May 1999 15:24:34 -0400
Message-Id: <9905081924.AA10036@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <003501be8a99$fff49140$e6ea7392@honeybee> (sv@crystaliz.com)
Subject: Re: WeDAV Versioning Summary


   From: "Sankar Virdhagriswaran" <sv@crystaliz.com>

   One way to state my objection to workspace is based on the fact that DELTA-V
   really covers 3 different (top level) concepts. The  first is the
   'transactional' semantics of cooperative development (often called
   cooperative transactions in CS research) with merge support.

Could you explain what you have in mind for "transactional semantics of
cooperative development"?  And how it is related to workspace functionality?

   The second is the notion of views on underlying data.

Workspaces do give you a flexible way of selecting revisions of
versioned-resources (e.g. the revision selection rule).  Requiring
that revision selection take place via a workspace gives the server
the opportunity of storing objects like configurations, labels, and
activities in an efficient format, while maximizing their version
selection performance when placed in a workspace.

   The third is the notion of
   workspaces that are used to perform work by individuals or groups.

By this I assume you are referring to the fact that working resources
are always associated with a workspace.

   I think  we should separate these three for modularity sake alone.

I'll wait for explanation on what the first concept is, but the second
and third concept are joined because any time you have a multi-resource
version-selection problem, you need to be able to deal with both revisions
and working-resources in a uniform way.

   APPLICATION REQUIREMENTS

   Additionally, for the type of applications we are thinking about, merge has
   two implications: 'consistency management' and the 'place where the merge is
   performed'. By tying these two closely, the protocol does not allow for
   merge schemes that do not assume a 'place' with a 'view' where users perform
   the merge activity (a counter example is a document to which merge is
   applied or a calendar that is merged with other calendars in a meeting
   maker).

There is no requirement that a merge take place in a workspace,
although there is a requirement that any new version be created
by checking out some versioned-resource in some workspace.

   In our way of thinking much of the information pieces (changes, change
   proposals, change sets, etc., etc.) are thought of as 'documents' which can
   be edited, shipped, shared, replicated, and done things to that you would
   expect to do a document. In this context, workspaces with view rules where
   merge is performed may be too heavy weight an object

A workspace can be as lightweight as a "checkout token" with a textual
revision-selection-rule property.  Although servers may chose to implement
them as a heavily optimized resource, there is no requirement that they do so.

   (and probably rooted in
   some 'place' according to the current spec.) and may not result in
   consistent behavior when shipped from one host to another (lacking global
   namespaces, etc.)

You can just ship around the revision-selection rule if you want to get 
consistent behavior between hosts (the working resources are of course
local to the workspace, though).

Cheers,
Geoff