2009/8/31 Wes Hardaker <[email protected]>:
> DS> My gut reaction is that get_tree()/get_node() are clearly internal APIs.
>
> You'd be wrong there actually.  I know for a fact people use them to
> locate mib information.  Both snmptranslate and snmptable call get_tree
> for example, and I think you'll agree there code contents that could
> very easily be used elsewhere.

I'm quite willing to believe that they are used.
I'm not even suggesting that we try to prevent this.
But that doesn't automatically make them public API calls, IMO.


I would suggest that the public API for translating an object name
into a numeric OID is "read_objid()".   That is what we should be
encouraging people to use, documenting, etc
   get_node() is an internal API, which is used by read_objid to
do this, but is not itself a public API.   If nothing else, it doesn't
even exist if MIB loading has been disabled!


As far as 'get_tree' is concerned, I'm not sure whether we need to
provide a public API for access to the internal MIB structure.
Fiddling with this sort of low-level MIB detail is not a core part of
most SNMP requirements.
   Even if we do need to provide such an API,  then I don't think
get_tree() is the right answer.   The name is not particularly
meaningful, and it shouldn't be necessary to specify the root
of the tree.
   I'd want to give this a bit more thought, but I suspect a MIB-related
public API would need to include quite a few more calls than we
currently offer.  If only to semi-protect the internal "struct tree"
data structure.


But I suspect the underlying issue may be what we each understand
by  "public API"  vs  "internal API".

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