On Thu, 2005-05-26 at 02:38, Vance Shipley wrote:
> I have an existing application for which I would like to embed a
> subagent. There are two tables to implement for which there exist
> data structures in the application.
The table_data helper would certainly work with that arrangement.
> The two data structures are fairly simple tables. One is a small
> table indexed by an unsigned char. The other is a larger table which
> is indexed by four unsigned chars.
Note that the data structure used by the table_data helper is
the structure of a single row (with or without the index values),
rather than the whole table.
> I had decided that table_data would give me the best mix of using
> the built in handling while still keeping the data externally.
Yes - that sounds a sensible decision.
The table_data helper would want to keep its own internal
representation of the table (so it would be taking care of
the indexing), but this could probably share the same data
structures with the main application.
You might need to be a bit careful about when such entries
were released (and who was responsible for freeing memory).
But there's nothing too hairy there.
> From my perspective, just picking this up now, it is unclear what
> constitutes an API here let alone
In terms of implementing a MIB table, there are probably
seven main module helpers that you could choose from:
- table: handles parsing indexes and not much else.
Most processing needs to be handled manually.
Not really regarded as a front-line table helper
- table_container:
- table_data: Very similar helpers
Both hold an internal representation of the table
using (user-defined) per-row data structures, and
handle all aspects of table indexing.
Interpreting the contents of a row is left to you.
'table_container' constrains the layout of the
per-row data structure, 'table_data' doesn't
- table_dataset:
Fully responsible for *all* aspects of the table.
Interprets the columns of a row as well as handling
table indexing.
You just have to deal with "special case" processing
- table_iterator:
Iteration hooks search an (external) representation
of the table, using arbitrary (user-defined) per-row
data structures. Handles table indexing.
Interpreting the contents of a row is left to you.
All these helpers use the same basic "handler" mechanism for
processing an incoming request. Most of them will identify
the row that you should be working with, and call your handler
routine to provide the appropriate column value.
- user_array:
- MfD These two adopt a different approach, using 'mib2c'
to define a series of column- or task-specific
routines. You could regard this as splitting the
flow of the handler in small, bite-size chunks.
Robert's the expert on these two, so could probably describe
them better than I could. It's been a while since I tried
to document them, and that task is still incomplete anyway.
But I'd tend to regard 'user_array' as a wrapper round
'table_container' (at least in terms of concepts), and 'MfD'
as a (more flexible) wrapper round either 'table_container' or
'table_iterator', depending on how mib2c was invoked.
Plus there's still the v4 UCD API, of course.
> let alone what is deprecated or bleeding edge.
Ummm...
Gut (personal) reaction:
iterate_access (not listed above) is basically obsolete
user_array is probably effectively replaced by MfD
steps are in hand to merge container and data
dataset is a somewhat more specialised approach
as is the basic table helper
the v4 API is more definitely deprecated
I'd say the most obvious choices would be between
'table_data' and 'table_iterate' (for a handler-based
approach), or the MfD style.
But that's very much my personal take - others may see
things differently.
Dave
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
