Re: snmpconf issue #1: language versioning

["Robert Moore" <remoore@xxxxxxxxxx>]

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
remoore@us.ibm.com



Steve Moulton <moulton@snmp.com>@snmp.com on 04/05/2001 02:13:44 PM

Please respond to snmpconf@snmp.com

Sent by:  owner-snmpconf@snmp.com


To:   snmpconf@snmp.com
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 <waldbusser@nextbeacon.com>
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
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com