On Tue, 2005-04-26 at 21:52, Robert Story wrote: > On Mon, 25 Apr 2005 17:02:13 +0100 Dave wrote:
> DS> In terms of public API, the main difference between table_data > DS> and table_container is in terms of how the indexing is handled. > > Actually, the real difference is that table_container doesn't have > an API at all. Eh? What does http://www.net-snmp.org/dev/agent/group__table__container.html describe then? And there's been a 'mib2c.container.conf' generator since 5.2. > So I'm suggesting that the table_data2 API become the table_container > API. There is no backwards compatibility implications. I disagree. The behaviour, API calls and data structures of table_container are fairly well established by now. As are those for table_data. And these are *different*. My view for table_data2 (under whatever name) is that it should retain the same APIs as table_data, but rely on table_container internally. As far as a MIB module developer is concerned, the important thing is that visible interface - the fact that it uses containers to hold the table is not relevant. With table_data, I can use a native data structure to hold a row of the table. So that should remain true with table_data2. With table_container, the per-row data structure *must* begin with the index information (in some specified format). So there *are* compatibility implications. Or have I misunderstood the container data structure? > DS> I'd suggest it's less confusing if the two different approaches > DS> are handled by two different helper. > > And of course, I suggest that a bunch of almost-the same little helpers > is just as confusing as one big helper. Fair enough - we'll just have to agree to disagree. > Following the 'simpler smaller helper' paradigm, table_container should be 4 > helpers: the core, and then 3 wrappers for each of the supported index > methods. That's up to you. Table_container is your baby, you can structure it how you like. I prefer to keep 'table_data2' as a separate helper. > Heck, table_data2 should even be split, it has two different ways of > handling indexes too. Not really. It has one basic (public) way for handling index values - as a list of separate varbinds, constructed using netsnmp_table_row_add_index(). This is then converted into a netsnmp_index structure for the benefit of the table_container helper, but that's a private internal thing. If we were working with C++, that field would probably be declared private. It's still got the old 'index_oid' field, but that's purely for backward compatibility with table_data. It's never actually used. And even with the table_data helper, my understanding was that this was also basically an internal mechanism anyway (the equivalent of 'netsnmp_index'). The public API for supplying index values has always been via netsnmp_table_row_add_index. That's my understanding anyway - Wes, care to correct any errors? Dave ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
