Subject: Re: snmpconf issue #1: language versioning

From: "Robert Moore" <[email-masked]>
Date: Fri, 6 Apr 2001 13:04:27 -0400

Steve,

I don't see how your second scenario helps.  If I write
a script today and don't start it with a test for the
capability PolicyScriptVersion1, then presumably I'm
also not going to start it with a test for the absence
of the capability (incapability?) noPolicyScriptVersion1.
So adding this incapability later doesn't help me.
In fact, I'm worse off than before.  You're trading a check
for the presence of a capatility PolicyScriptVersion1 that
would be defined now, for a test for the absence of an
incapability noPolicyScriptVersion1 that might be defined
later.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

Steve Moulton <[email-masked]>@snmp.com on 04/05/2001 02:13:44 PM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: snmpconf issue #1: language versioning

I see two scenarios.

.  We are able to maintain backward compability across the language
   releases.  Like Steve, I agree that this ideal, and likely.

.  We mess something up.  In this case, when we revise the language,
   we add two capabilities:  policyScriptVersion2, and,
   noPolicyScriptVersion1, which would indicate that some "features"
   of version 1 have been deprecated.

[Sorry about all the included text.]

     -s

On Thursday, April 5 2001, Steve Waldbusser <[email-masked]>
wrote:

>
> What we have on our side is that we're defining a subset of a very very
> well known language. So the risk is low that there is a hidden flaw in
> the base language. Perhaps we'll learn we made a mistake in the process
> of subsetting (i.e. we took something out that we should have left in).
> Perhaps over time we'll be willing to accept more implementation burden
> and want to add more in. Such changes are backwardly compatible.
>
> One reason I like this plan is because I'd like to avoid turning every
> 1-line filter (I believe many will be 1-liners) into 2-line filters with
> the inclusion of "if (capMatch(policyScriptVersion1)){". (I guess that's
> 3 lines with the closing curly brace).
>
> Instead I see people assuming the base language and if/when we add an
> extension, bracketing the use of the extension with the check:
>
>   some_policyScript_code;
>   if (capMatch(policyScriptVersion2)){
>     // use the new feature
>   } else {
>     // do it a different way
>   }
>
> Many scripts that don't use the extension won't check the version at
all.
>
> Steve
>
>
> Wes Hardaker wrote:
> >
> > >>>>> On Wed, 04 Apr 2001 10:24:37 -0700, Steve Waldbusser
<waldbusser@next
beacon.com> said:
> >
> > Steve> We agreed future versions must be backwardly compatable.
> >
> > I sure hope that the current language, as is, proves popular and
> > usable then.  You're playing with fire to think that you've developed
> > a brand new language that will receive perfect marks when deployed to
> > the world and needs no changes that won't be backwards compatible, but
> > I could certainly be wrong.  I'm just concerned (as I mentioned in
> > Minneapolis, I like the current language, but I haven't tried to do
> > anything complex with it yet).
> >
> > --
> > Wes Hardaker
> > NAI Labs
> > Network Associates

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Steve Moulton <[email-masked]>
Date: Fri, 06 Apr 2001 13:51:37 -0400

Good Afternoon, Bob,

Suppose that a feature is deprecated on a version change.

If your script depends on that feature

  .  If you check for PolicyScriptVersion1, you stop your
     script cleanly.  

  .  If you did not check for PolicyScriptVersion1, then your
     script would fail to execute, incrementing 
     pmPolicyAbnormalTerminations.

If your script did not depend on that feature

  .  If you check for PolicyScriptVersion1, you stop
     the script unnecessarily.  There is no way to check
     whether the feature change would have affected your
     script, since there is no way to know ahead of time
     what the feature change might be.

  .  If you don't check, your script executes as before.

If a feature is deprecated in a future version of the language, 
and you wanted to use that feature (say as a transition mechanism)
then checking for presence/lack of version 1 support may be useful.  
However, without knowing a priori what features might be deprecated, 
one is unlikely to write version checking code with those features
in mind.

Taking another perspective, say I have a bunch of scripts that I
have written for version 1 of the script language.  Version 2 comes
out.  Do I want to modify every script I use, or just the
scripts that depend on a version 1 feature?

I would prefer to modify only the scripts that would fail because
they depend on a deprecated feature.

This is assuming that no feature's functionality changes without 
that feature being deprecated.  This also assumes that we ever
deprecate anything.

I welcome a counter-example.  I have this feeling that I am missing
something.

	- Steve

---

From: Pablo Halpern <[email-masked]>
Date: Fri, 06 Apr 2001 15:28:50 -0400

Another way to approach this problem would be to forget about language 
versioning and talk only about specific features. Let us assume that in the 
in Version 2 of the language we add two new features to the language, 
featureA and featureB and remove featureX. (Aside: the word "deprecate" 
would be incorrect here, since deprecate just means the feature might be 
removed in the future and that its use is therefore discouraged. When a 
feature is removed, it has moved from "deprecated" to "unavailable.")  In 
Version 3, we add featureC and we change featureY in a way that is 
sometimes incompatible with Version 1.

The following are flawed:

capmatch(Version1)  might cause a perfectly-good script to fail if featureA 
or featureB are not used.

capmatch(Version2) might cause a script to fail on Version3 for no good reason.

Here are better tests:

capmatch(newFeatureA)    true on version 2 and 3 (and future versions)
! capmatch(removedFeatureX)  true only on version 1
! capmatch(v3FeatureY)   true on versions 1 and 2, but not 3 and over.
capmatch(v3FeatureY)   true on version 3 and over.

Get it?  By assigning a capability to each new, changed, or removed 
feature, we can test for only those features that will make our script work 
or fail. Any other feature can be assumed to be backwards compatible.

If, instead we added one capability for the version, then how do you test 
for "version 3 or later?"  One possibility would be to say that version 3 
must also include the capability for version 2. If a feature was removed in 
version 3, then you would test for

capmatch(Version2) && ! capmatch(Version3)

This would accomplish what I described above, but with fewer separate 
capability objects. It might be a bit confusing, though, to have a version 
2 capability on a version 3 system if it is not 100% backwards compatible.

This brings up the issue of an implementation supporting multiple versions 
of the Policy language. My question is how would you indicate which version 
of the language you want to use? It's one thing to abort the script when 
using the wrong version, it's another thing to somehow set the interpreter 
mode to the correct supported version.

- Pablo
----------------------------------------------------------------------
Pablo Halpern                      http://www.halpernwightsoftware.com
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: 06 Apr 2001 17:09:56 -0700

>>>>> On Fri, 06 Apr 2001 15:28:50 -0400, Pablo Halpern <[email-masked]> 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.

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.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Pablo Halpern <[email-masked]>
Date: Sun, 08 Apr 2001 13:49:39 -0400

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

>which is a boon in my opinion.  No one else seemed to like it though,

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                                    [email-masked]
http://www.halpernwightsoftware.com