[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 
> <phalpern@newview.org> 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 
is upgraded.

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 
versions.

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
---------------------------------------------------------------------
Pablo Halpern                                    phalpern@newview.org
http://www.halpernwightsoftware.com