On Thu, 2005-07-21 at 22:20 -0400, Robert Story wrote:
> turn-about is fair play, right? :-)

'Spose so.


> I was moving the notification_log mib stuff into the agent library
> today, and the cvs main version is based on table_dataset2.

Hmmm...
I must admit that I haven't done much with that particular helper.
I tend to work at the row level (table_data/data2/container).




> The data2 structure has the table container netsnmp_index and it's own
> index_oid/index_oid_len (which is labeled 'backwards compatability').
> Since this is a new helper, I would think that there would be no need
> for backwards compatability

My original intention was to replace Wes' 'table_data' helper
completely, so it felt important to keep the same field names.
The data2 structure therefore just added the 'netsnmp_index'
field that the container helpers rely on.

But it's subsequently proved impossible to use this as a straight
replacement.  So you're probably right, and we should drop the
separate index_oid/index_oid_len fields.

I'm in two minds as to whether the netsnmp_variable_list field
is worth keeping or not....



> Next, the  netsnmp_table_data2_build_result() function is marked obsolete,
> is empty and returns GENERR. However, it is still used by table_dataset2
> for get processing.......... A quick search didn't turn up a suitable
> replacement. What am I missing?

That doesn't really surprise me.
I was mostly working at the row level, so concentrated on getting
the 'table_data' helper functional.  And the approach I was using
didn't use this routine (see the 'mib2c.table_data.conf' output
for an example ).

The only place where the 'build_result' routine seemed to be needed
was in the table_data helper handler, as part of the GETNEXT processing.
With the table_data2 approach, this step is now handled by the
upper-level container helper, so this routine seem to be obsolete.


I never got around to reworking the table_dataset (perhaps to use
an internal container), so never spotted that this routine was
still needed here.  And I suspect that Wes just did a global
search-and-replace when constructing the table_dataset2 version,
so didn't realise that this code was still broken.


> Restoring the code (based on the table_data version) fixes things.

Sounds good.

Dave



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to