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

Re: snmpconf Proposed agenda for interim meeting

David Harrington wrote:
> It would be good not to have multiple interpreters in each device.

The script MIB doesn't dictate any language - it is independent of the
language, and thus the interpreter. So a script MIB implementation could
use only the PM language - it's up to the implementation.

Also keep in mind the requirements analysis for the language and the
execution environment: the language for the PM MIB is being designed so
that it can run on every managed device in an organization (spanning a
wide range of device capabilities). Disman's script MIB, on the other
hand, was designed to be run on those systems large enough to be given
mid-level manager characteristics (and burdens).

> One concern I have about the snmpconf language is the dependence on
> "magic" for the iteration; somehow the snmpconf engine "knows" how to
> iterate across the possible managed elements. It has been my experience
> as a programmer that computers are very poor at "knowing" what I intend;
> they only "know" what I tell them explicitly. I think it will become
> necessary to include iterator statements in our policies, or we will
> need to rely on some level of magic for the thing to work.

The "magic" has been eliminated with the addition of the
elementTypeRegistrationTable. This enabled very explicit instructions in
the spec on how the iteration works.

> If we make our
> design caompatible with disman, then users who like our
> policy-expression language and runtime environment can use it within a
> DISMAN environment;

Because of the design of disman's script MIB, a script MIB
implementation is able to use the PM language. They can do this today
regardless of the compatability of script mib objects with PM mib

> if they'd rather do policy using perl or javascript,
> they could use that within a disman environment; 

This is also something implementors have had the capability to do for
some time, well before the existence of the snmconf group.