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

Re: Some additional obscure questions... Forward Refs



On Mon, 3 Feb 2003, David T. Perkins wrote:

> I think you are trying to change the point, which is that examples
> to demonstrate conformance are more powerful when they check all
> aspects of the conformance instead of the trivial case. Of course,
> examples to "teach" about functionality would be written differently.
> And examples to show common practice would be different.

Agreed.

There are plenty of ways -- both contrived and not -- to come up with
examples of perfectly legal modules that simply cannot be dealt with
in a compiler without forward references.  If all one is dealing with is
an NMS that makes use of precompiled files with fully-qualified/absolute
OIDs, it's no big deal.  But you have to get there somehow.

I look at the IMPORTS as actually being the ultimate forward reference,
since there is no guarantee that the compiler is being fed modules in the
appropriate order.  One approach (one I definitely don't take) is to
suspend parsing of one module to go and parse the modules it imports (and
so on), but that only gets you so far.

Some examples of legal forward references (how contrived they are is up to
you):

EXAMPLE1-MIB DEFINITIONS ::= BEGIN
IMPORTS
   experimental, OBJECT-TYPE
      FROM SNMPv2-SMI
   OBJECT-GROUP
      FROM SNMPv2-CONF
   ;

   ...

   groupAsParent OBJECT-GROUP
      OBJECTS { object1, object2, ... }
      ...
      ::= { experimental 99999 }

   object1 OBJECT-TYPE
      ...
      ::= { groupAsParent 1 }

   object2 OBJECT-TYPE
      ...
      ::= { groupAsParent 2 }

   ...

END

No matter which order you put groupAsParent, object1 and object2 in the
module, you've got forward references.  (Note that this is not necessarily
an example of a good practice -- most modules do not define objects
subordinate to the groups they are in, and some recommend against it.)

EXAMPLE2A-MIB DEFINITIONS ::= BEGIN
IMPORTS
    oidFrom2B
       FROM EXAMPLE2B-MIB
    experimental
       FROM SNMPv2-SMI
    ;
    ...
    oidFrom2A OBJECT IDENTIFIER ::= { experimental 99999 4 }
    aaa OBJECT IDENTIFIER ::= { oidFrom2B 1 }
    ...
END

EXAMPLE2B-MIB DEFINITIONS ::= BEGIN
IMPORTS
    oidFrom2A
       FROM EXAMPLE2B-MIB
    experimental
       FROM SNMPv2-SMI
    ;
    ...
    oidFrom2B OBJECT IDENTIFIER ::= { experimental 99999 5 }
    aaa OBJECT IDENTIFIER ::= { oidFrom2B 1 }
    ...
END

Obviously this example is much more contrived than the other, but if you
take the approach where you suspend parsing of one module to go off and
parse the modules in its IMPORTS then it's similarly impossible to deal
with this.

Of course, there are some potentially arguable drawbacks to supporting
forward references, too, but they tend to fall into the "taking the easy
way out" category in my book:

RECURSIVE-OID-MIB DEFINITIONS ::= BEGIN
...
   oid1 OBJECT IDENTIFIER ::= { oid2 1 }
   oid2 OBJECT IDENTIFIER ::= { oid1 2 }
...
END

If you don't support forward references, you'll bomb out on this (as you
should) easily.  If you do support forward references, then you have to be
careful to not get caught by the recursive references.


--
Michael Kirkham
www.muonics.com