Re: Repository -- do we need it?

Sankar Virdhagriswaran (sv@hunchuen.crystaliz.com)
Tue, 4 May 1999 10:48:45 -0400 

Message-ID: <007501be963d$36673ee0$d0acddcf@crystaliz.com>
From: "Sankar Virdhagriswaran" <sv@hunchuen.crystaliz.com>
To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
Cc: <ietf-dav-versioning@w3.org>
Date: Tue, 4 May 1999 10:48:45 -0400
Subject: Re: Repository -- do we need it?

> The latter.  A workspace provides a "version-selection" mechanism that
> maps from versioned-resources to revisions and working-resources.  A
> repository holds the versioned-resources, activities, configurations,
> and workspaces.
>

Thanks. Now that I understand what repositories are, I have a thought that might
help. I think (I am not sure about this ...) that repositories may help achieve the
modularity I was asking for. Ignoring versioned resources for the moment, I think of
activities, configurations, and workspaces as 'namespace service providers'. They
provide particular kinds of organization on top of 'data'.  If we allow clients to
access the repository through these 'namespace service providers', in an orthogonal
fashion, then we may be able to achieve the orthogonal I was hoping for. For example,
a sophisticated client can use the configuration namespace service provider and the
activities namespace service provider to implement a change-set based consistency
management system and can ignore workspaces. Similarly, (as Geoff mentions) a simple
browsing client can just allow 'managers' to browse the various namespaces for
administrative purposes or build a way of navigating related changes (i.e.,
activities) and user tasks (i.e., workspaces) for what is often referred to as
'change tracking and management'.

NOTE: some argue that even versioned resources should be implemented as based on an
'artifactual' system. If that implementation strategy was chosen by some of the
implementers, even versioned-resources data in the repository becomes a namespace.
From watching the discussion in the DAV list I have a feeling that only a few
implementers think this way about versioned resources, therefore I mention this point
in a note rather than to substantiate the main point of supporting having a
repository specification just based on orthogonality and extensibility.

I think that my proposal is different from Geoff (am I right Geoff?). I think he
wanted to have a repository (as in a database) specified as part of the protocol for
mostly 'administrative' uses. I think I am actually extending his idea to have the
repository as a set of namespaces that can be used by DELTA-V clients in an
orthogonal fashion to perform their function, not just use it for administrative UI
purposes.

Hope this helps in making us come together.

Sankar

PS: Also, if the advanced collections is specified correctly, these 'namespace
service providers' can be implemented using advanced collections. Our implementation
is based on such an architecture.