Re: Repository -- do we need it?
Sankar Virdhagriswaran (sv@hunchuen.crystaliz.com)
Wed, 5 May 1999 13:35:24 -0400
Message-ID: <004e01be971d$ab25a790$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: Wed, 5 May 1999 13:35:24 -0400
Subject: Re: Repository -- do we need it?
> I believe that "collections" are the only namespace service providers.
> Activities, configurations, and workspaces group things, but not for
> the purpose of giving them names.
>
Why not? (see below where I expand on the concept of my twist on repository)
> The resources being defined are designed to be orthogonal, but not
> redundant. So activities, configurations, and workspaces are not
> different flavors of the same thing, but rather very different things
> that serve different purposes.
>
I understand this. I did not think that they would be redundant.
> of them. If you blur the distinction between them by requiring that
> they each perform the function that the others provide, a server
> no longer can peform the optimizations that are essential if this
> protocol is going to be useful for large-scale applications.
>
I was not proposing the structure.
> to operations, a server *cannot* effectively optimize for large scale
> applications by caching information between requests.
>
I understand this. However, for those cases where this type of caching will actually
create problems and for those cases where workspace concept actually gets in the way
of designing appropriate clients I would like to have the ability to not use
workspaces to perform the kind of selections.
> What is "an implementation that is based on an artifactual system"?
>
Basically, each new state of any versioned entity gets a new, globally unique-id. In
other words, each state is considered to be an 'artifact' (in the archeological sense
of that word) - i.e., it is immutable. Version names, etc. are all overlaid on top of
this unique-id scheme as a 'namespace'.
>
> Just to reinforce my earlier point, orthogonality does not imply that
> you can have just one without the other. Sleeping and eating
> are orthogonal issues, but that doesn't mean that you
> can chose to just sleep and never eat, or vica versa.
>
I did mean orthogonality in the sense you are using it. Not in the 'redundant' sense.
> I'd have to see more specifically what "extending a repository to
> be a set of namespaces" means, but if it means that a repository performs
> all the functions of a workspace, a configuration, and an activity, then
> that would be a very different proposal.
>
Yup ;-). Just to explain about this notion of a collection of namespaces and the
notion of namespace service provider, let me use the example of Java Naming and
Directory Interface (JNDI). JNDI provides a common API for querying and navigating
different (typically) graph structured namespaces which can be federated. They also
have a way of implementing particular implementations of this API using 'service
providers'. They have implemented service providers for navigating file systems,
CORBA name space service objects, LDAP directories, etc. One can imagine implementing
such a service provider for configurations, activities, and workspaces. In
particular, workspaces are similar to LDAP service providers because LDAP service
providers actually have to support sophisticated querying on the data they maintain.
Does this all make sense to you? I know that I am describing an implementation
strategy. However, that implementation strategy does have an impact on how orthgonal
the protocol could be.
> that is designed to scale will be able to reuse its general
> collection implementation for a more sophisticated construct like a
> "configuration", is vanishingly small.
This is true and I agree with you. I have not been tracking the advanced collections
spec. development as closely as you have been. So, may be I way off the mark.
However, I thought the advanced collections spec. as it evolves looked more and more
like JNDI (given the discussion about resources and how resources are actually mapped
to different things and given the discussion about bind and unbind). So, I was making
the suggestion about 'implementation' in the sense of JNDI service providers.
That is, in my mind, the advanced collection spec. would provide a general set of
protocols to create/modify/delete collections and to navigate them. Once could then
'implement service providers' that implement this protocol for different types of
specific collections we care about (compound document collections, configurations,
activities, etc.). Hope this helps in clarifying.
>This means that the
> server will need a separate configuration implementation,
Yes (and for workspaces, etc.). I fully agree with this.
> at which
> point any methods required by the collection protocol that are
> not really needed for the configuration protocol are actually a
> *burden* on the server implementor, not a benefit.
>
This I don't agree. In general what you say is true - generality has burdens on
specific implementations. However, there are advantages to going with the approach I
am proposing. Client writers have to learn one 'regime'. We found this to be very
useful when we did our implementation. Our client writers (who were not as
sophisticated as our server writers) had to learn one way of
creating/modifying/navigating different namespaces. Also, API's such as JNDI and
CORBA collections spec. and Java 1.2 (i.e., Java 2) collections API actually show
different ways of achieveing our objectives.
Imagine the other case. I need to educate our client writers with the basic DAV
protocol methods, the advanced collections protocol methods, the configuration
(collection) protocol methods, the activities (collection) protocol method, the
workspace (collections) protocol methods (and DASL). Folks won't be able to swallow
all the subtle differences between each of these methods.
Even after implementing a system such as the one that we are developing in DAV, I
(personally) cannot keep all the different variations in my mind. This is partly due
to terminology and partly due to spending only part time on the WEB-DAV activity.
Still, I hope you see my point.
thanks for listening
Sankar