Subject: Re: snmpconf issue #1: language versioning

From: "Robert Moore" <[email-masked]>
Date: Wed, 4 Apr 2001 08:14:35 -0400

Maybe I'm missing something obvious, but ... if you
don't register version 1, how does a manager tell
(by querying the Capabilities table) the difference
between an agent implementation that supports only
version 2 of the language, and one that supports
both version 1 and version 2?

Regards,
Bob

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

Wes Hardaker <[email-masked]>@snmp.com on 04/03/2001 08:30:29 PM

Please respond to [email-masked]

Sent by:  [email-masked]

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

>>>>> On Tue, 03 Apr 2001 01:35:35 -0700, Steve Waldbusser
<[email-masked]> said:

Steve> In the Pittsburgh meeting we agreed to #2 except that we
Steve> wouldn't bother registering the initial version of the
Steve> language. If we make a modification we would register that
Steve> version. Nobody's going to put capMatch(version1) at the
Steve> beginning of every script particularly when there's only 1
Steve> version (and we wouldn't want to lead people to believe they
Steve> should). When the second version comes out and you want to use
Steve> features from it, you can first test with capMatch(version2).

Ahh.  No one mentioned that at the last meeting when I brought it up.

Anyway, thats fine by me.  I can't think of any reason to force a v1
registration.  The only vague answer I can come up with is that if a
manager was querying a cap table to see what version of a script to
upload, it wouldn't have to match against every known version type to
determine if it was a v1 script engine.  Minor minor point though.

--
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: 04 Apr 2001 07:20:55 -0700

>>>>> On Wed, 4 Apr 2001 08:14:35 -0400, "Robert Moore" <[email-masked]> said:

Robert> Maybe I'm missing something obvious, but ... if you don't
Robert> register version 1, how does a manager tell (by querying the
Robert> Capabilities table) the difference between an agent
Robert> implementation that supports only version 2 of the language,
Robert> and one that supports both version 1 and version 2?

Right, I knew there was another reason.  But people previously stated
that they only wanted the engine to support "one" version, though I
was hoping that registering multiple versions would indeed be
possible.

I agree, lets add a version.1 oid.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 04 Apr 2001 10:24:37 -0700

We agreed future versions must be backwardly compatable.

Steve

---

From: Wes Hardaker <[email-masked]>
Date: 05 Apr 2001 08:43:53 -0700

>>>>> On Wed, 04 Apr 2001 10:24:37 -0700, Steve Waldbusser <[email-masked]> 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

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 05 Apr 2001 10:53:07 -0700

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

---

From: Steve Moulton <[email-masked]>
Date: Thu, 05 Apr 2001 14:13:44 -0400

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

all.
> > anything complex with it yet).

---
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: Wes Hardaker <[email-masked]>
Date: 06 Apr 2001 17:14:36 -0700

>>>>> On Thu, 05 Apr 2001 10:53:07 -0700, Steve Waldbusser <[email-masked]> said:

Steve> What we have on our side is that we're defining a subset of a
Steve> very very well known language. So the risk is low that there is
Steve> a hidden flaw in the base language.

No, but we might have hidden flaws in the functions we're defining and
making use of.  I'm not saying the constructs of the language will
change, I'm saying how it is used will.  You've already gotten rid of
"int" in favor of the more generic "var" variable type between the
last version and the new.

Steve> Such changes are backwardly compatible.
...

And there is our philosophical difference.  I'm not convinced we won't
want to make backwards incompatible changes.  You're saying that all
implementations from now on must, for example, implement the
setRowStatus() function from now on, regardless of whether it's
replaced by a more generic "createRow()" function in the future (that
implements both createAndWait and createAndGo).  IE, the
setRowStatus() function will always be around since the next version
of the document is likely to have it.  (sounds suspiciously like
Windows ;-)

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 06 Apr 2001 21:20:10 -0700

Wes,

  Aha - We might have been talking past each other here. You're talking
about accessor functions. The language and the library are registered
separately. The base library (with all the functions in this document)
is already registered under pmBaseFunctionLibrary ::= { policyMgt
pmConformance pmGroups 4 }

Steve

---

From: Wes Hardaker <[email-masked]>
Date: 30 Apr 2001 09:14:13 -0700

>>>>> On Fri, 06 Apr 2001 21:20:10 -0700, Steve Waldbusser <[email-masked]> said:

Steve> Aha - We might have been talking past each other here. You're
Steve> talking about accessor functions. The language and the library
Steve> are registered separately. The base library (with all the
Steve> functions in this document) is already registered under
Steve> pmBaseFunctionLibrary ::= { policyMgt pmConformance pmGroups 4
Steve> }

Which, by the way, is one thing we'll miss by dropping the
capabilities table: the ability to register our own libraries.

-- 
Wes Hardaker
NAI Labs
Network Associates