On Mon, 03 Oct 2005 16:53:22 +0100 Dave wrote:
DS> I get the impression that most of what you've said is
DS> concerned with the specifics of this particular helper.
DS> Did you have any thoughts about this as an example of
DS> a more general API framework? Any operations that
DS> felt to be missing?
What, you actually want me to think about it, instead of shooting the fish
in the barrel? ;-)
DS> > (You did know you could use containers without netsnmp_index, right?)
DS>
DS> Ummm... no.
DS> I'd got the impression that the 'table_container' helper *did*
DS> require netsnmp_index. See the comments immediately following the
DS> three key types in table_container.c. Is this wrong?
DS> If so, then we could revert to using 'netsnmp_table_row' again
DS> (but see later).
In theory, so long as the container compare routines do the right thing, it
should work. In practice, I've never tested a table using varbind indexes.
DS> > This is a nice generic API, how about simply trow? A table row API
DS> > and a table data API?
DS>
DS> I'm not quite sure what you mean by this. Is this the same
DS> table-independent/table-specific distinction mentioned above,
DS> or something different?
The former, I think.
DS> > I don't like having two index methods in the structure. It's a waste of
DS> > space. I'd rather see a union, and let the user determine which they
DS> > want to use.
DS>
DS> No - this is an internal structure, and the user shouldn't be fiddling
DS> with it (or even looking at it). Think in terms of the distinction
DS> between snmp_session and snmp_sess_session.
Ok, but I still see wasted space.
DS> > I was surprised that this didn't include something to deal with
DS> > saving default values for columns, to be used during row creation.
DS>
DS> I'm not at all sure what you mean by that.
DS> Rather than responding to a (probably erroneous) guess, perhaps you
DS> could expand a bit?
I was thinking of the table-specific stuff... Doesn't
table_data/table_data_set keep a row with default values?
DS> > > netsnmp_tdata_replace_row();
DS> [...]
DS> I'll drop it unless/until we come up with a clearer idea of
DS> the intended use.
Good.
DS> > > netsnmp_tdata_row* netsnmp_tdata_get_first_row(netsnmp_tdata
DS> > > *table); netsnmp_tdata_row* netsnmp_tdata_get_next_row( netsnmp_tdata
DS> > > *table, netsnmp_tdata_row *row);
DS> >
DS> > Suggest a wrapper using the new container iterator stuff too, which
DS> > would be much more efficient for someone traversing the whole table.
DS>
DS> But these routines already use the CONTAINER_{FIRST,NEXT} macros.
DS> Won't that pick up the appropriate container iterator mechanism?
DS> I can't help feeling that I've missed the point here.
Nope. Next will find the next item based on the given key, which means it has
to find the given item first. So using NEXT on an array with 10 items will
perform 10 searches.
The iterator stuff has knowledge of the internals, requires a pointer to keep
context. Thus iterating over 10 items will (increment internal index | advance
internal next pointer | etc) for efficient traversal.
DS> Anyway, enough of this general agreement - it's boring!
DS>
DS> > > int netsnmp_tdata_add_row();
DS> > > void *netsnmp_tdata_delete_row();
DS> > > void *netsnmp_tdata_remove_and_delete_row();
DS> > > netsnmp_tdata_row *netsnmp_tdata_remove_row();
DS> > > netsnmp_tdata_row *netsnmp_tdata_create_row(void);
DS> > > netsnmp_tdata_row *netsnmp_tdata_clone_row(netsnmp_tdata_row *row);
DS> >
DS> > I though we agreed on object before function in function names? eg
DS> > netsnmp_tdata_row_(add|delete|remove|...).
DS>
DS> The trouble with those names is that they are ambigous.
DS> Does 'netsnmp_tdata_row_add' mean
DS> "add a row to a tdata table"
DS> or
DS> "add a tdata_row (to something - what?)"
This particular example is muddied by the confusion between tdata and
tdata_row, and using trow instead of tdata_row (as I proposed before) would
clarify things.
DS> RPN is fine for scientific calculators, but us mere humans are
DS> usually happier with "operand operator operand" syntax :-)
DS> So I'd agree with using a common prefix (netsnmp_tdata)
DS> for this API, but I'm reluctant to adopt too deep a stack
DS> of operands.
I'd like to get a wider range of opinions on this, as I disagree.
DS> > > netsnmp_tdata *netsnmp_tdata_create(const char *name);
DS> >
DS> > create what?
DS>
DS> Create a "tdata" table.
DS> Which rather supports the point above.
Actaully, I think it supports my suggestion for tdata + trow, rather than
tdata + tdata_row.
DS> > (note, if tdata_row is renamed to trow, this is no nonger
DS> > ambiguous and objection is withdrawn).
DS>
DS> Eh?
DS> I don't follow that at all.
DS> This API doesn't make any mention of rows whatsoever???
Then what is a tdata_row? It's used as a parameter all over the place..
--
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 SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
