Re: Version issues
Dylan Barrell (dbarrell@opentext.com)
Mon, 26 Apr 1999 12:18:34 +0200
Message-ID: <01BE8FDE.E80D25C0.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'Sankar Virdhagriswaran'" <sv@crystaliz.com>,
Cc: "Falkenhainer, Brian" <Brian.Falkenhainer@usa.xerox.com>,
Date: Mon, 26 Apr 1999 12:18:34 +0200
Subject: RE: Version issues
Comments below
Cheers
Dylan
On Saturday, April 24, 1999 2:24 PM, Sankar Virdhagriswaran
[SMTP:sv@crystaliz.com] wrote:
> Dylan,
>
> While on the face of it your proposal looks reasonable, I would like to
> submit to you an alternative view. Jim W has already brought the
> combinatorial explosion and hence I won't repeat it. I have two points
that
> are different.
>
> Point 1:
>
> Your argument does not hold for collaborative development through change
> sets and configurations. Change set based systems do not typically expose
> version level operations to their clients. In the currently evolving
> versioning protocol spec., I can see how change set based systems can
work
> by using configurations and activities.
I agree!
>
> If the group takes up your proposal, then vendors who use change set
based
> approach *have to* support *versioning semantics* at the protocol level.
> This does not make sense for those vendors at all.
If this is the consensus, then I agree that versioning should also be
optional.
>
> However, I do support the following statement in your message whole
> heartily:
>
> > Confining my comments purely to the goals document I think it is
desirable
> > to have orthogonality of support of various "areas" (for lack of a
better
>
> This is just good design methodology. However, determining levels of a
> protocol is based (IMHO) more on market and deployment reasons.
If everyone agrees, then let us make this an explicit versioning goal!
>
> Point 2:
>
> Our protocol design is happening within the context of HTTP 1.1, DAV, DAV
> advanced collections, and DASL. If you were to put these together you
will
> see that your position creates a lot of problems. I am still puzzeled by
the
> position that says simple versioning as supported by systems such as SCCS
> can work in the context of DAV. First, there is the question of 'linked
> object consistency management'.
Is totally orthogonal to what level of versioning (even none) is supported
by the server.
> Second, just recently, there has been
> discussion of the HTTP resource model in the advanced collections group.
I
> cannot see for the life of me how simple versioning works for the
advanced
> collections model being developed by that group such that the end users
life
> is made easy.
Can you give an explicit example? I cannot imagine why not!
> Yes, one can shoehorn simple versioning in the context of
> multiple bindings, etc., but without proper configuration management that
> will become incredibly difficult.
We must be careful not to argue on terms which haven't been properly
defined. Before I get into this argument about "simple versioning" and
"proper configuration management", I would like to understand what we are
actually discussing.
>Third, in the past, there has been talk of
> variants (based on language variants) in the DAV group. Again, I cannot
see
> how variants can be supported *simply* (from a user interaction
perspective)
> with a simple versioning model.
This is totally orthogonal. A variant is simply a translation of a revision
to some other format (be it language, document format or character set
encoding etc. etc.). If you view the resources as a tree with the
"variantable" (whew!!!) nodes as leaves which can sprout at various points
on the stem, then variants can be viewed as blossoms which sprout from the
base of a leaf. Some leaves have no blossoms, some have multiple. Variants
are never versioned. The base variant is versioned (master).
>
> So, my point (hope !!) is that while many vendors are asking for support
for
> simple versioning, after the first cut interaction with their customers
who
> are involved in authoring a hyper graph of collections of resources in
one
> or multiple languages, they will find out that simple versioning is not
so
> simple at all. Therefore, I am very reluctant to support any position
that
> favors simple versioning based on arguements that are based on experience
in
> the file system world which cannot be mapped to the hyper graph world of
the
> Web. After all DAV and DELTA-V are about the Web, right? We are not doing
> this protocol design over TCP/IP, but *extending* HTTP.
I don't think we should ONLY support "simple versioning", but rather that
not all versioning functionality is necessary for the majority of servers
and therefore we need different levels of support. Failure to do this will
result in many vendors having to provide functionality they do not actually
need to provide in order to be WebDAV versioning compliant.