Quoting Robert Story <[EMAIL PROTECTED]>:
> I was thinking that mayb table_data2/table_row could just go away.
> It's really just a few wrapper functions around table_container,
> so I'd say move those functions into table_container, and do away
> with table_data2.
Nope. Not in favour of that.
The significant difference between table_data/data2/row and the
container lies in the data structure used. The table_container
helper forces a particular format to the per-row data structure,
with explicit fields to hold the formatted index values.
The table_data helper (and variants) works with an arbitrary
per-row data structure - the index values are held external to this.
I think that's a useful flexibility. In fact, I prefer the
table_data helper for that very reason. The container helper
has a superior internal implementation, but the table_data helper
has the better visible API (IMO).
> As for dataset2, I have some idea there too. Are you sitting down? I've
> actaully been thinking that it probably wouldn't be that hard to use the
> dataset2 stuff underneath MFD, eliminating a great deal of code that MFD
> currently generates in the *_interface file.
In principle, I'd agree. That sounds like a good idea.
> If you don't mind signing up for
> lots of arguments with me, I think we could try and bring the best
> features of all the current handlers into this one.
Ummm....
What sort of timescale were you thinking of?
I'm up for the arguments - this feels like a good way to proceed.
But I *MUST* get That Bloody Book out of the way first. I've taken
a calculated gamble in coming back to active involvement with support
of the project. That may well prove a little premature, and I
expect to drop out again (temporarily!) some time in the next few
months.
But that sort of design debate is likely to require a much
greater level of commitment than I can safely undertake.
So I'd say - yes, but not yet.
Dave
>
> DS> - At some point in the future (perhaps after having beefed
> DS> up the warnings for a couple of major releases), say
> DS> "hang backward compatibility" and replace 'table_data'
> DS> with a 'table_row'-based wrapper.
>
> I've always been a proponent of identifying all the obsoleted/redundant code
> and putting ifdefs around it, so it can be turned off.
>
> --
> 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 message was sent using IMP, the Internet Messaging Program.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
