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

Re: snmpconf issue #1: language versioning




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


Wes Hardaker wrote:
> 
> >>>>> On Thu, 05 Apr 2001 10:53:07 -0700, Steve Waldbusser <waldbusser@nextbeacon.com> 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