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

Re: snmpconf #4: Code reuse



Just my 2 cents:

I agree with Wes that we need a decent mechanism for code reuse in the 
policy language. I've been part of debates as to which accessor functions 
should or should not be put into the language. We tried strike a balance 
between completeness and minimalism. That balance will be wrong for some 
people. A function-call mechanism gives the user a way to make up for the 
general functions we left out as well as to write functions that are 
specific to his/her needs.

I agree completely with the ranking Wes gave to the options he described 
Specifically:

I  prefer #2 (implement functions in the policy language) although there 
would need to be a method of registering functions (not hard).

Of the other options, #3 (add functions as an optional capability) is the 
cleanest but, for the reasons mentioned, would probably discourage portable 
code.  Works well for device-specific policies.

I think #4 (a gosub(function-number) call) could be extended to take a 
single additional argument, which would be retrieved by the called function 
the same way policy arguments are retrieved. I don't see any advantage to 
this over #1 except to be able to say that we stuck to the initial decision 
not to have true functions. (A foolish consistency ...)


At 11:28 AM 4/2/01 -0700, you wrote:

>Options as I see it (I'm not going to describe how each one "could" be
>done, as this message would get far too long.  If feedback (consensus)
>is given that one should be explored more, I'd be happy to elaborate
>on an item at that time):
>
>1) Leave things as they are without changing the document.  This is
>    probably the easiest option.  I suspect, however, that as we get
>    into the point of interoperability and even more likely deployment
>    and usage tests this will come back to bite us.  I doubt it'll be a
>    huge problem until then.
>
>2) Implement function definitions in the base language.
>
>    Problems: This was previously decided not to be done.
>
>3) Implement functions as a new capability, registering the "function"
>    capability in the capabilities table.
>
>    Problems: It's beyond a basic capability.  How to deal with
>      some machines that don't have functions and others do?  To a
>      large extent, if you had any that didn't you'd write your code
>      ignoring (and suffering from) the reuse problem.
>
>The following suggestions all have one problem:
>   - the first index to the code table is explicitly managed by the
>     Filter/Action tables and creation of new entries is currently
>     prohibited by the description clause of pmPolicyCodeProgramIndex.
>     This would have to be dealt with in order to implement any of the
>     below.
>
>4) Implement a "gosub(codenum)" style function that calls the
>    functionality of another code block.
>
>    Problems:
>      Values would have to be passed via something like the scratchpad,
>      for instance.
>
>
>5) Implement a "link to" set of columns in the pmPolicyCodeTable.  The
>    definition for a given segment isn't stored here, but rather in a
>    different code/segment base.  Two new columns would be needed,
>    something like otherCodeIndex, otherCodeSegment.  When the policy
>    engine hit this row it would check to see that the code definition
>    was "", and refer to these numbers to find the real location of the
>    code (or else run-time-error).
>
>    Problems:
>      Kind of hacky feeling.
>
>6) Implement a "copy from" column in the pmPolicyCodeTable.  It would
>    copy code from a different code  so that
>
>    Problems:
>      Copies from an entire code entry, or just a segment.  If from an
>      entire entry the value should be the int pointing to that
>      segment.  If a segment, however, two values are needed which
>      would require two additional columns and a "doit" button or
>      something.
>
>      Tracking: if code is copied, it is not updated later and all
>      entries must be updated by the manager.
>
>
>My personal opinions:
>
>   1)   this will bite us later if don't fix it now.
>   2)   this is the way to go, IMHO, but I won't attempt to argue this point.
>   3)   This is probably the next best thing to do.
>   4-6) ugly, but "could work".  I'd prefer 4 and probably think 5 and
>          6 aren't worth the trouble.
>--
>Wes Hardaker
>NAI Labs
>Network Associates

- Pablo
----------------------------------------------------------------------
Pablo Halpern                      http://www.halpernwightsoftware.com
phalpern@newview.org