RE: New requirements draft

Jim,

Thanks for your patience. I am not familiar with the process. As you 
say, I have been repeatdly raising the concern.

Note: In the following message, I pick on variants a lot. Not because 
I don't want variants or not because I feel that it is useless, but 
because variants bring similar issues to configurations. My apologies 
to folks who have variants high in their order of importance.

> The appropriate time to have raised these concerns was during the
> two week
> working group last call period which ended last Friday.  Comments
> now
> should be specific to those additions made to the document since 
the
> end of
> the WG last call.
>
> However, the versioning support should not preclude the future
> development
> of configuration support.

This statement is what I hung on to. In other words, I assumed that 
the first version (!!) of the Web-DAV protocol will not preclude 
interoperability of clients and servers that would want to deal with 
configurations.

> ==> The requirements document does not mention support for
> configurations.
>  This is intentional.
>
> I honestly do understand the utility of configurations, and hence 
my
> lack
> of desire to provide support for configurations is not based in
> ignorance
> of their virtues.  Rather, my objection to configuration support is
> based
> on my perception that there are thorny, complex issues surrounding
> this
> topic, and my belief that the state of the art may not yet be
> sufficiently
> advanced to standardize such functionality.
>
> For example, while we could provide support for freezing the state
> of a
> collection, and provide check-in and check-out capability on a
> collection,
> this avoids the difficult issue of determining what should be the
> membership of that collection.  Should the membership be only the
> release
> "2.0" members, or should it be the result of a search on the values
> of some
> properties, or should it implement a change set system?
>
> At present, I see a trend in the software CM tools industry towards
>
> providing change set capability.  However, this is different from
> the
> majority of current CM systems.  If we were to chose a change set
> solution,
> how would this map to legacy versioning repositories?  In fact,
> chosing any
> one way of placing the members inside a collection will undoubtedly
> favor
> some systems, and preclude others.
I have several points to make on this line of arguement.

1) The position you take on configurations is in-consistent with the 
position taken on variants. As I have said in an earlier message, 
variants are more complex than the discussion has pointed out so far. 
In the Product Data Management (PDM) domain, variants (as in 
alternates) are dealt with in fairly complex ways, i.e., issues 
surrounding variants have the same level of complexity as issues 
surrounding configurations. Yet, the current requirements document 
specifically includes variants and excludes configurations. 
Therefore, it is hard for me to buy the fact the arguement against 
configurations is based on the complexity of the issue.

2) Similarly, if you pick one way of dealing with variants (yet to be 
determined, but along the ways discussed by Judith and others) it 
will necessarily affect the PDM folks. Yet, we leave variants as a 
requirement and not configurations.

3) Yaron has been trying to convince everybody that variants can be 
"developed on top of" what already exists. This is the same arguement 
you provide for configurations. And yet, we leave variants in and not 
configurations.

4) You say that the state of the art on configurations is not 
advanced. Hmmm,...I find this hard to believe. How many commercial 
tools do I have to point to say that they all have notion of 
configurations (ClearCase, Documentum, AutoDesk workcenter, ours, 
etc., etc.). How can we argue that configurations are not advanced 
when many, many users use it today.

So, I don't see how we can leave variants in (as a requirement mind 
you) and not configurations. As I have said before, architecturally 
speaking they bring about the same type of issues to the table.

Furthermore, since I don't really know what is the state of affairs 
with respect to properties and versioning in DAV, it is hard for me 
to answer how one would deal with the variable ways in which 
configurations are dealt with.  See my last point.

> ability to version individual resources.  Functionality related to
> configuration management will be accessed either locally,

I agree that without configurations the Web-DAV protocol is still 
useful. Mind you what I am asking for is the same as what folks 
interested in variants are asking for. Currently, there is no 
consensus (as I watch the discussion) about a way to deal with 
variants, yet...

But, what you say in the first part of the above is not an answer. 
This is like saying why have Web-DAV at all. Why don't we pass 
modified URLs.

Secondly, configuration management in many of the tools I mentioned 
above is inherently tied to what is also called workspace management 
where versions are addressed relative to the configurations. This is 
not a local operation (if I understand you reference "locally"), this 
is a naming and dereferencing issue over the wire. Therefore, it 
fundamentally affects the protocol.

via the
> configuration management program's native interface, or via one of
> the many
> Web user interfaces, e.g., Forms, Java applets, etc.  To me this
> sounds
> like a "have your cake and eat it too" situation -- all clients can
> depend
> on the frequently used versioning primitives, while advanced users
> still
> get the benefits of configuration management.

Nope, this cannot work if some authoring tool wants to access a 
version relative to a configuration and the configuration + version 
information is actually served up. It is a fundamentaly issue with 
respect to naming objects that are versioned and de-referencing them.

> So, the distinction is that the full range of configuration
> management
> capability will still be accessible, however, it may not be
> interoperable.

Hmmm...this is a change of position from your earlier position that 
has been quoted earlier in the message. Interoperability is why one 
needs protocols, no?

>  Hence, to convince me, and this working group that configuration
>  support
> should be included in the requirements document you need to 
convince
> us why
> it would be a "bad thing" if configuration support were not
> *interoperable*.

Two responses:

1. The working group ought to be consistent in its stands. Could you 
tell me why it would be a "bad thing" if variants are not dealt with. 
If your criteria is that 80% of the customers are what you are 
serving, then variants should be dropped from the requirements.

2. It is a bad thing to the high (future) end of the version control 
market. Making a market oriented argument, in terms of $$, that 
market segment dwarfs the version control market segment. May be a 
lot less number of copies, but lot more $$. If you drop it the 
vendors in that space are going to be affected. To me. much of the 
requirements on variants and some of the lock discussions has been 
dominated by what I call as high end requirements (a difference 
typically seen in the debates between Yaron and Judith or Yaron and 
Darrell).

3. Technically speaking there are several reasons:

a) It is a bad thing because it has to do with clients exchanging 
names with servers in a particular way and if we don't address it, 
then anyone who wants to write configuration functionality will have 
to get into the core of Web-DAV server request/response stream. The 
configuration resolution has to happen before any part of the Web-DAV 
server deals with the URI that is passed through the request. This 
becomes even more hairy with collections. To emphasize, I am 
concerned about configuration relative addressing. This is a name 
resolution issue. In my way of thinking this is too central to any 
protocol for it to be left.

b) Believe me intercepting an HTTP request/response stream in 
commercial servers is not fun. Anyone who wants to add configuration 
management functionality will have implement to n different APIs and 
there is no guarantee that the servers will give the URI reslution 
over to the plugins. Every revision of the existing commercial 
servers come up with completely different ways of doing this. Making 
vendors who are interested in configurations do this is *very bad*

c) Once you deal with dereferencing variants, then you will begin to 
deal with a sub-set of the issues that one sees in configurations. 
Dereferncing a variant of a resource is similar (not the same) as 
accessing versions relative to configurations.

> but is unconvinced of the need to develop an interoperability
> specification
> for configuration functionality right now.
>

Hopefully, this note has helped. Just as there are "n" different ways 
of implementing versions - i.e., naming versions, storing deltas of 
them, and reconstructing a named version from its deltas, there are 
also "n" different ways of naming and accessing configurations. But, 
just as in version naming you can safely ignore implementation issues 
when specifying a protocol, you can also safely ignore implementation 
issues in configurations and yet specify a protocol that works. 
Finally, it is a *bad thing* to not deal with configurations now 
because it has to do with *naming and identity of objects* that 
configuration aware Web-DAV clients and servers have to deal with. 
And, it is the larger of the market compared to version based 
systems.

Received on Wednesday, 24 September 1997 09:19:08 UTC