Quoting Wes Hardaker <[EMAIL PROTECTED]>:
>                      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.....
> All of their code was going to be non-compilable in the
> future which I didn't think was fair.

No, that's perfectly sensible.
But I'm surprised you say that the *dataset* helpers would break.
Don't they just rely on the data helper?

I knew that stepping through the table_data lists would fail,
but that never felt to be pushed as a user-level helper.
(Thoguh it's actually a more useful one, IMO).   But surely
the whole point of the dataset helper was that the table
storage was internal?  The APIs for retrieving individual
values would still work, so why would things break?


> I am entirely to blame there for doing it so quietly (I expected you
> to jump right after the CVS message went by actually). 

I was on sabbatical, remember.  I'd unsubscribed from everything
bar the coders (and admin) list.  I'm trying not to get sucked in
as deeply as before, so I'm still not on the CVS or tracker lists.
(That's also why I haven't been doing the list admin stuff either).



> 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

But we also need to catch the people that are *already* using it.
Hence the idea of a warning.



> 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:

>   3) a user specifically requested it to be compiled in.
> 
> Somewhat akin to the current --with-mib-modules flag really, but for
> the helpers.

<nods>
That's a good idea.
It might even be possible to provide a table_data wrapper round
the container-based mechanism, that's only included if the "real"
table_data helper isn't.   (Similar to the exec/extend handling).


>            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.

Yup - I'd go with that.

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/listinfo/net-snmp-coders

Reply via email to