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

Re: snmpconf #4: Code reuse



My own inclination is either (1) [Don't do functions] or (2) [Do 
functions].  The various "sort of" solutions that Wes described (including 
making it a capability) all seem like bad compromises.
Yours,
Joel M. Halpern

PS:  I am slightly inclined to leave them out.

At 11:28 AM 4/2/01 -0700, Wes Hardaker 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