[David - we've strayed rather from your original suggestions.
Do you still want to be Cc:ed explicitly, or would you
rather just follow this (or not!) via the list? ]
Dave> But unless you're very careful (and understand the library
Dave> rather better than I do), initialising the SNMP aspects of the
Dave> library will end up initialising the MIB side too.
Wes> Well, yeah, if you call the default init_snmp().
So how ami (Joe Random Programmer) meant to initialise the library
for SNMP use, if I don't *want* to initialise the MIB side as well?
Wes> (we should have a
Wes> default_store boolean set to not-load-mib-objects).
That's one approach, certainly.
But I was actually thinking about taking a leaf out of your
agent-MIB-module initialisation book, and having some form of parameter,
that could be used to control which modules were initialised, or not.
I'm a little unconfortable about the danger of a proliferation of
default_store requirements (or set_not_load_mib_objects() type
equivalents). This sort of ties in with the configuration design
proposals in the other thread.
I'm not sure whether either a config-token style approach, or
the initialisation-token mechanism outlined above, would be more
understandable to the programmer - but I'm pretty sure it would
be more maintainable and documentable.
[Oh yes, Wes - brace yourself - I'm going to propose that we document
all of this new design much more comprehensively and consistently
than we do at the moment. Sorry to break this to you at such an
unearthly time in the morning, but if you _are_ fool enough to log on
at such an hour..... ]
But the whole initialisation area is one of the issues I'm still trying
to think about. I haven't really got any form of comprehensive proposal
for initialisation just yet (though it is an area that needs to be thrashed
out). If you want to toss some ideas in the air, then feel free.
Dave> cd snmplib
Dave> make libmib.a
Dave> and build a library that contained *just* the routines from mib.c,
Dave> parse.c and such utility routines that they rely on.
Wes> Right, we've talked about that for years. I once even started to
Wes> write a makefile to do it but got discussed with how obnoxious it was
Wes> to try and implement without breaking backwards compatibility,
As you may have noticed - I'm not worrying too much about backwards
compatability anymore :-) The problem as I see is isn't so much about
compatability, as untangling logically separate bits of the library.
Once we've got what we want to do sorted out, then we can go back and
think about minimising the impact.
Wes> and thought to myself "Well, Dave will do it eventually so I don't
Wes> have to!" :-)
I'm trying to decide if I've just been insulted, or complimented!