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

Re: snmpconf issue #1: language versioning




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