2009/9/1 Wes Hardaker <[email protected]>:
> DS> If nothing else, it [get_node] doesn't even exist if MIB
> DS> loading has been disabled!
>
> read_objid is fairly useless even if it exists.

Umm.... I'm not sure what you mean by that comment.

As I see things:
   With MIB loading enabled,
        read_objid("system") - the public API call
                will return the numeric OID array
        get_node("system") - the internal API call
                will also return the numeric OID array

   With MIB loading disabled,
        read_objid("1.3.6.1.2.1.1") - the public API call
                will return the numeric OID array
        get_node("1.3.6.1.2.1.1") - the internal API call
                won't even link!

That's one of the reasons why I don't think get_node
can be regarded as part of the public API.



> DS> But I suspect the underlying issue may be what we each understand
> DS> by  "public API"  vs  "internal API".
>
> True.  I think that isn't a big enough set of things to lump things
> into.  At a minimum I think we need:
>
>  - advertised API (read_objid should fall into this)

Agreed - that's what I've been calling the "public API"


>  - exported API   (get_tree *does* fall into this, even if we no longer
>                    wanted it to; it's been in example code since CMU)

Fair enough - that will cover a lot of what I've been calling the "internal API"


>  - private APIs   (historically we've had too few of these, I agree.
>                    But at the same time I strongly disagree with the
>                    notion that almost everything should go here.

No disagreement from me.
And that's probably a useful categorisation (with or without Magnus'
distinction between exported and non-exported private APIs).

I've really been concentrating on the advertised/exported boundary,
and haven't been too bothered about the detailed status of what
I've been calling the "internal API".   By definition, everything not
part of the advertised/public API _will_ fall into "exported+private"
i.e. the catch-all internal API.

  My aim has been initially to try and look at the set of main API calls,
that would probably cover 90% of typical usage.   If we can identify
this public API, ensure it's properly documented, and there are no
glaring omissions, then that's a good start.

But I'm inclined to concentrate on that first, before getting caught up
in sorting out the details of the exported/private distinction.


Dave

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to