- From: Sankar Virdhagriswaran <sv@crystaliz.com>
- Date: Wed, 24 Sep 1997 09:26:20 -0400
- To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
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