factoring of DAV services

This brief answer is in reference to the question asked by Larry. In our
system we factor the following services:

a) Delta based version storage
b) Version management
c) Meta object
d) Configuration management, and
e) Workspace management

The key in (a) is an ability to identify deltas by name and to associate
some meta date to the delta (in order to properly support merge). (b)
essentially becomes name management. Meta objects in our case is more than
the attribute/value pair or links pointing to large documents. We use a
multiple-inheritance based object model (particularly useful in Product
Data Management). Configurations are snapshots that contain many versioned
objects and configuration management has to deal with serving up
configurations as versionable objects. Finally, workspace management has to
deal with creating a "place" in which users prepare and committ many long
term transactions (i.e., in this case configurations). Workspaces have a
notion of views and there is a view service provided. Again, in our
implementation, each of these services can be separated across different
servers.

We believe that the above approach can lead to very large scaling of a DAV
system. I can't tell if these considerations have gone into the design of
the current protocol.


Sankar Virdhagriswaran			p. no: 508 371 0404

Received on Sunday, 4 May 1997 21:50:46 UTC