On Fri, 2005-04-29 at 16:17, Toth, Gregory S wrote:
> > The 'get_first' routine should return some sort of pointer to the
> > first row of the table (and will only be called once). The 'get_next'
> > routine should take this pointer, and return the equivalent pointer
> > for the next row.
> In my case the table data does not actually exist in a table. All the
> snmpget/getnext requests result in calls to external entities... In
> this situation, I would think the concept of returning a pointer to the
> first row or to the next row is meaningless.
Sorry if I gave the wrong impression.
By "pointer" in the above, I meant "some way of referring to a
particular row". It doesn't necessarily mean a variable pointing
to a specific memory location (though it typically is just that).
What's relevant here is *something* by which the iterator loop can
keep track of how far it's got through the table so far, and refer
to the appropriate next row.
> A get to (column 1, row 1) might result in a corba request
> "getTemperatureOfLeadingEdge(....)", where a get to
> (column 1, row 2) might result in a corba request
> "getTemperatureOfTrailingEdge(...)"
Note that the iterator splits the row/column handling in two.
The get_{first,next} routines are *only* concerned with determining
the appropriate row, and don't touch the column at all.
The handler takes this row, and retrieves the appropriate
column value.
> My intention is that in the xxx_handler, the "switch
> (table_info->colnum)" will use the colnum and the row to
> determine which corba/pro-c method to call to get the data:
In which case, I'd question whether the iterator is an
appropriate choice of helper for you. In fact, if you're
mapping different rows into completely different CORBA calls,
I'd be half tempted not to use any of the specialised table
helpers at all, and work directly with the main 'table_helper'.
That will handle the basic validation of the columns, and
index parsing. The rest you'd have to handle yourself.
> switch (table_info->colnum){
> case COLUMN_TEMPERATURES:
> switch(rowNumber){
> case 1:
> getTemperatureOfLeadingEdge(....)
> case 2:
> getTemperatureOfTrailingEdge(....)
>
> In this case where do I get the rowNumber? Is it
> table_info->oid[index_oid_len]?
In general, the index values are available via
'table_info->indexes' as a series of varbind values
(ignoring the name field).
For a single integer index, then *normally* this
would be 'requests->requestvb->name[N]' (where N is
'requests->requestvb->name_length')
But that assumes this is a complete (and valid) OID.
If the request refers to an incomplete or invalid OID,
then just looking at the last subidentifier isn't enough.
And of course, if this is a GETNEXT request, then you'd
have to skip on to the next row anyway.
All that is the sort of thing that the specialised helpers
normally take care of for you. But they need to have some
way of determining which rows are actually valid. Which
is where the iterator 'get_{first,next}' hooks come in.
Dave
-------------------------------------------------------
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
