On Tue, 2009-09-01 at 13:53 -0700, Wes Hardaker wrote:
> >>>>> On Tue, 1 Sep 2009 08:48:20 +0100, Dave Shield
> >>>>> <[email protected]> said:
>
> DS> But that doesn't automatically make them public API calls, IMO.
>
> Ok, understood.
>
> DS> I would suggest that the public API for translating an object name
> DS> into a numeric OID is "read_objid()".
>
> Sure, if that's all they wanted. I may even give you that get_node
> could be marked as internal if we were going to start from scratch. But
> telling people suddenly a gazzilion years that the functions used in the
> example apps/ directory (which is routinely where we tell people to look
> when they want to write management and mib related code) seems unwise.
>
> You may not want it to be public, but I'd argue it is at this point.
>
> DS> If nothing else, it doesn't even exist if MIB loading has been
> DS> disabled!
>
> read_objid is fairly useless even if it exists.
>
> DS> As far as 'get_tree' is concerned, I'm not sure whether we need to
> DS> provide a public API for access to the internal MIB structure.
> DS> Fiddling with this sort of low-level MIB detail is not a core part
> DS> of most SNMP requirements.
>
> In order to write a generic, but intelligent, manager you need to know a
> lot about the data in the mib tree. IMHO, it's critical to offer
> support for that sort of thing.
>
> DS> Even if we do need to provide such an API, then I don't think
> DS> get_tree() is the right answer.
>
> Room for improvement certainly exists everywhere ;-)
>
> 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)
>
> - exported API (get_tree *does* fall into this, even if we no longer
> wanted it to; it's been in example code since CMU)
>
> - 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. If
> functionality isn't publicly exported then people
> *will* try and use the private APIs because that's
> the only way they can get at a feature they need)
I think there need to be more granularity.
- advertised API is as Wes describes it. This is what I would like to
mark with some kind of NETSNMP_EXPORT tag that could expand to
__dllexport on windows and __attribute__((visibility("public"))) on
linux.
- exported API is also pretty much as Wes describes it but with a snag,
it might get replaced by another way of doing the same thing and a
compatibility function in some lib that isn't part of the default
build.
I fear that these also would need the NETSNMP_EXPORT tag.
- private exported API is things that have to be exported for technical
reasons- These might change unexpectedly-
- private non-exported API is static functions and variables. This is
what I think should be the default for new code unless there is a
reason to expose it further.
------------------------------------------------------------------------------
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
