Re: WeDAV Versioning Summary
Sankar Virdhagriswaran (sv@crystaliz.com)
Mon, 19 Apr 1999 15:20:42 -0400
Message-ID: <003501be8a99$fff49140$e6ea7392@honeybee>
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
Cc: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Date: Mon, 19 Apr 1999 15:20:42 -0400
Subject: Re: WeDAV Versioning Summary
Geoff, Jim
I was away on travel and am still deluged with work. Just so that the issue
of workspaces does not get lost, I want to send a brief note about the
reasons for my objections. I hope to do better based on questions I might
get.
My objections are based on two reasons:
a) Modularity, and
b) Application requirements
thinking about using the DELTA-V protocol in the context of two
applications that you folks may not have considered. Unfortunately, I do not
have the time to write up the scenarios or the detailed specifications we
would need. Therefore, my points (below) may sound theoretical, but they are
not.
MODULARITY
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. The second is
the notion of views on underlying data. The third is the notion of
workspaces that are used to perform work by individuals or groups. I think
we should separate these three for modularity sake alone.
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).
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 (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.)
Hope this helps.
<soapbox>
My philosophical bent is that versioning, configuraiton management, and
cooperative transaction management are useful in many different application
contexts. Considering that the DAV advanced collections will (hopefully)
provide a way to develop many different kinds of applications that use
'structured collections', I hope that we do not limit the utility of DELTA-V
in those other application contexts. It feels to me that the design team has
leveraged your experience in file system based configuration management in
specifying the semantic model so far. However, that may be a very small part
of the type of applications that would want to use DELTA-V given that we are
working in the context of base DAV (is there a different name for this
thing?), DAV advanced collections, and DASL. These three components of DAV
are much more general and hence I am hoping that DELTA-V will also allow
support for such generality for a variety of applications.
</soapbox>
PS: For your own exercise, think about how one can construct a syndicated
product catalog system with DELTA-V, DAV advanced collections, and DASL.
Then you may begin to see why I am not too happy with the close tie-in
between workspaces and merge support.
PPS: I donot understand what Geoff mentions as automatic merging support.