RE: Proposed Simplifications to the DeltaV protocol

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   I was very excited about the "feature sets" idea because I
   understood that these would be a normative part of the
   specification, not merely an informative thing.  Language is always
   so slippery....

We did discuss the idea of explicitly adding in "package" tokens to be
returned by OPTIONS, but the consensus at the meeting was that
returning explicit "package" tokens from OPTIONS (in addition to
"feature" tokens) would provide no additional benefit beyond simply
defining the package membership in the spec.

The rationale was that it's just as easy to check whether a set of
feature tokens are in the OPTIONS response as it is to check whether a
single package token is in the OPTIONS response).

   My assumption: If anybody can create a new "feature set" and inform the
   world what their set is, then there's no value to feature sets.

That does not follow.  If the spec identifies 4 specific feature
sets that a server SHOULD support, then a client is provided with
guidance as to what 4 feature sets to look for.

   I do, however, understand that some servers will want to support a
feature
   set plus an extra feature or two.  So I propose that there be some way to
   name each feature set, plus to name features on top.  Then the OPTIONS
   response for my server would indicate:
    - I support BASE feature set
    - I also support features X and Y (which are not part of BASE)

A client can answer the first question by just looking to see whether
all the features in the BASE feature set came back from the OPTIONS
request.  No need for a separate "package" token to be defined or
returned.

   Another server might support BASE, feature X, Y and also Z.  If BASE + X
+ Y
   + Z == FEATURE_SET_1, then the OPTIONS response would only have one
string
   for this server:
    - I support FEATURE_SET_1

Similarly, it's just as easy for a client to check whether all features
in FEATURE_SET_1 have been returned in the OPTIONS response from the
server.

   Also, I would propose that BASE replace the concept of CORE.  It's way
too
   confusing to have a difference.  BASE should be the set of features that
all
   servers must implement:  the old concept of core, plus checkout, plus
   fork-control parsing (even if disallowed).

CORE is the intersection of the features supported by all defined
packages.  This turns out to just be one feature, namely, the
version-control feature.  It doesn't matter much to me whether we
give that single common feature its own package name, as long as
we clearly identify that this is the only feature that is common
between all packages.

   Taking these steps puts few actual restrictions on the servers.  They can
   still decide to support an arbitrary set of features.  There is only a
   psychological pressure (which I think is a good thing) to implement a
   defined package rather than a random set of features.  The next value of
   this is that it's much easier for a client to identify their supported
   feature sets.

I believe that the difference in coding effort and complexity between:

   for (feature in package)
     check-if-feature-supported (feature, supported-feature-set)

and

   check-if-package-supported (package, supported-package-set)

is not sufficient to warrant adding package tokens to the OPTIONS
response.

Cheers,
Geoff

Received on Tuesday, 17 April 2001 15:59:03 UTC