>>>>> On Fri, 22 Apr 2005 20:41:47 +0100, Dave Shield <[EMAIL PROTECTED]> said:
>> 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
Dave> OK - that makes sense.
Dave> (Apart from the strange US way of counting.... <grin>)
Dave,
I can't believe I forgot to write up my rational in the end. I know
it was my intent at the time to fix the problem then write about it.
I even agree that was backward. But, in fact, the reason I changed it
back was because you had committed code that I was positive would break
existing people's code out there. When the dataset stuff was
originally published it did receive a moderate amount of attention and
I know for a fact it was being used based on the questions we
received. All of their code was going to be non-compilable in the
future which I didn't think was fair.
Now, I also completely agree with *why* you wanted to use something
different and applaud the work. Thus I reversed it, changed the name
to '2' which I meant to talk about later (even the name change was
actually quite a pain). I do agree we should call it something else.
I'll even be happy to do the renaming for you if you like if you tell
me what you want it to be named.
#3 above... err... #3.1 I guess was a real problem. We had code
that we knew worked fairly recently, had to immediately publish a
reference copy and found that it had broken since we last used it.
I am entirely to blame there for doing it so quietly (I expected you
to jump right after the CVS message went by actually).
Actually, the other thing you don't know is that the net-policy
project is actually publishing the net-snmp cvs snapshot from that day
because I knew the net-snmp admin's wouldn't go for a cvs publication
from our site. :-/ Net-Policy 2.1 required something beyond 5.2.1
unfortunately so we had no choice.
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!
Agreed. I'm up for anything.
Dave> - (re-)instate the "get_first"/"get_next" API calls
Dave> as wrappers round the linking list pointeres.
I do think that this should have been done when I originally wrote the
code. I even planned on doing it before it made it into a real
release, but you know that goes...
Dave> - add a "deprecated warning" message to the table_data
Dave> registration call (probably with a flag to turn it off!)
Dave> That should actively encourage people to start using the
Dave> API calls, rather than fiddling with the links directly.
I'd think that we should stop advertising it altogether. Pull the
documents that talk about it, pull the mib2c files that generate it
and I've already ensured that all the existing code in the tree
contained your rewrites using the 2 base (except for the table
emulation code which broke).
Dave> - At some point in the future (perhaps after having beefed
Dave> up the warnings for a couple of major releases), say
Dave> "hang backward compatibility" and replace 'table_data'
Dave> with a 'table_row'-based wrapper.
I actually think we need to better deal with "selectable" pieces. IE,
code should only be included in the libraries if either:
1) internal code is using it.
2) it's something we advertise as good to use even though it's not
used internally
3) a user specifically requested it to be compiled in.
Somewhat akin to the current --with-mib-modules flag really, but for
the helpers. I don't think we're doing anyone a service by deleting
it entirely unless it's broken for some reason. But warnings are a
good thing and removing it from the default set in the future is a
good thing.
--
Wes Hardaker
Sparta, Inc.
-------------------------------------------------------
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/listinfo/net-snmp-coders
