[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf issue #1: language versioning
At 05:09 PM 4/6/2001 -0700, Wes Hardaker wrote:
> >>>>> On Fri, 06 Apr 2001 15:28:50 -0400, Pablo Halpern
> <email@example.com> said:
>Pablo> capmatch(newFeatureA) true on version 2 and 3 (and future versions)
>Pablo> ! capmatch(removedFeatureX) true only on version 1
>The only problem with the above is that feature X may not be assumed
>to be a "feature" but is a core specification right now. What happens
>if, for instance, we don't declare the feature "createAndWaitRow"
>function now, but decide to remove it later in favor of the new,
>frequently discussed already, createRow which does either
>createAndWait or createAndGo. Old scripts will break if the previous
>function (ie, feature) is removed and not checked for.
Given that most changes to the language (or one of the libraries) will be
backwardly compatible, I think that we need to accept that old scripts will
break if they use a "feature" that is removed or changed in a future
version. The idea is that when the new version comes out, you can put
checks into your older scripts. If you get in the habit of always checking
versions and always aborting if the "wrong" version is found, then many of
your perfectly-good scripts will unnecessarily abort when the policy agent
We should plan so that the most common case is the easiest. Here are the
three cases as I see it:
1. Most scripts will work on all versions of the Policy Language
2. Some scripts will work on newer versions, but not older versions.
3. A few scripts will only work on older versions or only with specific
My solution requires that no changes be made for case #1 (the most common).
Case #2 requires that the script test the version (or feature used), but
that test can be put into the script when it is first written, requiring no
changes later on. Case #3 requires modifying the script after it has been
written, but should be (by far) the least common.
>Pablo> This brings up the issue of an implementation supporting
>Pablo> multiple versions of the Policy language. My question is how
>Pablo> would you indicate which version of the language you want to
>Pablo> use? It's one thing to abort the script when using the wrong
>Pablo> version, it's another thing to somehow set the interpreter mode
>Pablo> to the correct supported version.
>I originally suggested that uploaded code have a column indicating the
>version number of the code in question. This leaves no room for
>errors and doesn't require "if (version1)" wrappers around anything,
>which is a boon in my opinion. No one else seemed to like it though,
>but I suspect you might.
Again, this penalizes the majority of scripts, which will work with any
version (or at least with any version greater than a certain number), even
if the version it was written for is not directly supported on the
agent. If the number were the *minimum* version number, that would help,
but would not prevent problems with features that were removed or changed
in an incompatible way.
I'm wondering if we're trying too hard, though. Perhaps we should admit
that most agents will support only one version of the language at a time.
If there existed a simple scalar indicating which version that was, then a
script could test for a single version, a version range,
greater-than-or-equal, or nothing. This would probably handle 99% of the
situations. How hard do we want to work to allow an agent to support
multiple simultaneous versions of the Policy Language?
Pablo Halpern firstname.lastname@example.org