On Fri, 29 Apr 2005 13:52:45 +0100 Dave wrote:
DS> On Thu, 2005-04-28 at 00:47, Robert Story wrote:
DS> > Think of table_container as a cake. The container conf
DS> > is red frosting.
DS>
DS> I'd regard the mib2c.container.conf as describing the bare
DS> cake. It doesn't imply any frosting at all.
The what is the table_container, without container.conf? Flour, water, butter,
etc? Ok, then container is a red cake, mfd is a purple cake, etc.
DS> > table_data2 is green frosting. All I'm
DS> > saying is that the cake could/should come with a tube of
DS> > green frosting.
DS>
DS> It could - and that tube would be labelled "mib2c.data2.conf"
Ok, but that would mean that anyone not wanting to use mib2c would have to make
their own frosting/cake. That seems silly to me, when we've got a perfectly
good frosting/cake (table_data2) that they could use, in code (or perhaps via
snmpd.conf file tokens) without having to run mib2c.
DS> But I think you should also be able to make a plain cake
DS> (mib2c.container.conf) that doesn't have any frosting on
DS> at all. The idea of having to scrape off all the green
DS> frosting before you start is Just Plain Wierd!
Note that I said it came with a tube, not that the tube was applied. I really
think that forcing them to run mib2c to be able to use table_container is
excessive. Either that, or they have to know that table_data2 is a pre-existing
wrapper. I just thought that since table_data2 is intimately tied (internally)
to table_container, and table_container has no API (in code, pre-existing in
the library), and table_data2 is in need of a new name, that it was a match
made in heaven.
I've had the really strong feeling for a few days now that you aren't grasping
the basic idea I'm trying to present. It's a simple pairing that offers a
simple API for table_container, while having absolutely no effect on any other
existing code or mib2c generated code. i.e. all benefit, and no cost. You keep
mentioning perceived problems, but to date none of them have been actual
problems. Every idea that you've mentioned would work regardless of what
table_data2 is renamed to, or what file it is compiled in.
So, given that there is no cost, I guess you just don't see any benefit in the
merging. I see a simplification of the net-snmp API, merging a perfectly good
API with it's internal implementation.
At any rate, it's your API and I've run out of energy for this argument. A
table_container API will just have to wait til I have the time to add one.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
