Re: terminology challenge

[Andy Bierman <abierman@cisco.com>]

At 09:43 AM 12/17/2001, Juergen Schoenwaelder wrote:

>>>>>> Andy Bierman writes:
>
>Andy> I've noticed that not all of us are using the same terminology
>Andy> to talk about SMI concepts (not again!).  We have a real
>Andy> challenge here, because MIBs are used by three distinct
>Andy> communities:
>
>[...]
>
>Andy> We need to figure out a coherent terminology (and syntax BTW)
>Andy> which is user-friendly to all three communities.
>
>I think it is of key importance to use terms that are widely used and
>understood. And if we support modeling beyond what is available in C,
>we better use terms from C++ or Java rather than inventing our own
>terminology. BTW, even Perl claims to support OO programming these
>days (although the Perl OO system is rather perlish).


I agree -- the terminology should be consistent with the syntax
and data model that we use.  I think the WG decided not to attempt to
add machine-readable elements of procedure, or method routines.
I think the WG agreed that we don't want partial inheritance,
and only wanted single inheritance.  We aren't really providing OO features.

I think the types of data structures we are likely to need
for describing management information are more C-like than C++ like.  
We have examples all over the current MIBs of what should be
STRUCTs in STRUCTs, UNION of SCALARs, UNION of STRUCTs, ARRAYs in ARRAYs, 
and many other combinations. 

The "textual footprint" of the GenericCounter UNION is 4:1 or 5:1 
smaller than SMIv2, without losing any semantics, while dramatically 
improving readability for (32,32/32,64) counter tuples. (And it matches the
agent representation, making agent implementation easy.)


>/js

Andy