[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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