2009/8/28 Jan Safranek <[email protected]>:
> as Dave suggested, here is attempt to rename MIB to NETSNMP_MIB2_OID.
> Notice I did not rename any other identifier in the header file, IMHO it's
> a bit late now.
Definitely - the smaller the changes we make at this point, the better.
> And I am still a bit confused what is internal and public API
Not surprising. We've never really been clear about making this distinction.
That's exactly the issue I was trying to start addressing with the earlier
changes - to start clarifying what were public APIs, and what were internal.
The rule of thumb that I'm using is to think about a coder - implementing
a fairly straightforward client application, or MIB module. Stuff that they
would naturally want to do (constructing/sending SNMP requests, and
interpreting the results) would be public APIs. Anything else would be
internal.
Now that's obviously an overly-simplistic approach, and there are bound
to be awkward corner-cases. But it seemed a reasonable first-cut.
> there is plenty of identifiers which are now pulled by
> snmp_client.h
> and which do not have netsnmp_ prefix and are generic enough that they
> could conflict with an application - like get_tree(), get_node(), struct
> variable_list etc.
My gut reaction is that get_tree()/get_node() are clearly internal APIs.
While the varbind structure is obviously part of the public API.
Also bear in mind that 'snmp_client.h' is part of the original CMU file
structure. Within my recent re-structuring, it's actually part of the
internal API definitions, rather than the public API.
The public API is basically the stuff defined at the top-level of the
'include/net-snmp/' tree. The internal APIs is the stuff under 'library'.
(And that's leaving aside the the internal/public split for the agent API)
> Anyway, that's definitely different story, let's focus on fixing immediate
> problems with 5.5.rc2. With the patch below, apcupsd compiles successfully.
>
> I don't think that suggested NETSNMP_NO_LEGACY_DEFINITIONS is good idea -
> the application would see the old identifiers by default. IMHO it is better
> to advertise the new ones and show the old only if application (or
> its packager) explicitly ask so.
That's not the policy we have been following up to now.
Our approach has typically been to try and keep backwards-compatibility
wherever possible. If someone has code that has been using the old
definitions and identifiers, then these should continue to be available
by default. It's only if a coder needs a "clean" namespace, that they
would turn off these old definitions.
Now none of us would argue that this dirty namespace is a good thing.
But it's probably an inevitable (if unwelcome) consequence of the
piecemeal development of the {CMU/UCD/Net}-SNMP codebase.
In an ideal world, we wouldn't be starting from here. But throwing
everything away and starting again just isn't realistic - believe me,
I've tried!
Unfortunately, you've identified a situation where the default position
doesn't work. I'm not sure what the best way forward is, but I
think it's going to require some flexibility on the part of apcupsd.
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
