Re: table_data helpers

This is a discussion on Re: table_data helpers within the SNMP Coders forums, part of the Networking and Network Related category; Quoting Robert Story <rstory@freesnmp.com>: > DS> Hmmm.... where was this discussed? > > I think ...


Go Back   Usenet Forums > Networking and Network Related > SNMP Coders

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-22-2005
Dave Shield
 
Posts: n/a
Default Re: table_data helpers

Quoting Robert Story <rstory@freesnmp.com>:
> DS> Hmmm.... where was this discussed?
>
> I think this was an executive decision by Wes because:
>
> 1) the table token was broken
> 2) no easy way to fix 1 in container version
> 3) work influences needed a working cvs, ASAP
> 3) new container version still exists, but renamed


OK - that makes sense.
(Apart from the strange US way of counting.... <grin>)


> I think #3 prevented the normal discussion before the change, but it
> probably should have been brought up afterwards. We were under a work
> deadline that distracted us, unfortunately.


Say no more. That's only too familiar :-(


> DS> I never much liked the 'data/dataset' names anyway.
> DS> If we're going to change them, I'd like a say in what to!
>
> I can pretty much guarantee that there won't be any issue with renaming
> them. The existing name was just so that he could get the reverted code
> back into cvs asap, so as not to appear that the concept was unacceptable.


OK - I'm currently thinking along the lines of "table_row" and
(possibly) "table_rowcol" - given that the data/data2/container
helpers look after the rows of the table, and dataset looks after
both the rows and the columns.

I was also mulling over the future of the (original) table_data helper
on the way down to the train this evening. Given that the main
problem seems to be the lack of a clean way of iterating through
the rows of the table, how about the following:

- (re-)instate the "get_first"/"get_next" API calls
as wrappers round the linking list pointeres.
They may still be there, I haven't checked. But it
wouldn't affect backward compatibility.

- add a "deprecated warning" message to the table_data
registration call (probably with a flag to turn it off!)
That should actively encourage people to start using the
API calls, rather than fiddling with the links directly.

- At some point in the future (perhaps after having beefed
up the warnings for a couple of major releases), say
"hang backward compatibility" and replace 'table_data'
with a 'table_row'-based wrapper.

How does that sound?

Dave

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 11:47 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0