On Tue, 14 Jun 2005 09:38:43 +0100 Dave wrote: DS> On Mon, 2005-06-13 at 21:05, Magnus Fromreide wrote: DS> > On Mon, Jun 13, 2005 at 03:54:14PM +0100, Dave Shield wrote: DS> > > I've just committed a patch to the main development tree, DS> > > that renames the offending routine in the Net-SNMP source, DS> > > while leaving an (optional) compatability wrapper. DS> DS> > Would similar patches to remove other just as ugly warts be considered? DS> DS> That was the intention of proposing this mechanism, certainly. DS> Matthew's problem was simply a particular example of a more DS> general issue. We've started trying to define cleaner API DS> names for new code, but there's a lot of potentially ambiguous DS> earlier stuff. DS> I'd hoped to trigger a discussion of whether this approach DS> seemed a sensible way forward.
I think it's a perfectly reasonable way to deal with name conflicts in existing/old apis. DS> > My first choice to kill would then be the PACKAGE_* macros. DS> DS> Ummm... isn't those a standard part of the configure mechanism? DS> The main "configure" script certainly gives that impression. This dead horse has been beaten before. The problem is that net-snmp-config.h would need to be split into two. One file (which would contain the package macros and other various stuff) that would only be used when building the net-snmp libraries and applications, and another that contained the stuff necessary for end-users. Unfortunately, Wes disagrees. DS> > What is the transition plan for deprecation of the old calls? DS> > This is actually a general question - how old code should be supported? DS> DS> Well, the first thing is probably to agree on whether this is an DS> appropriate mechanism or not! :-) The particular define, NETSNMP_CLEAN_NAMESPACE, is not, but the general idea is. DS> If we can gradually start to separate "current" APIs from those DS> we consider obsolete, then we've got a chance to work towards a DS> clean, core API for those that need such a thing, while retaining DS> the existing melange for those that just want code to keep working. I think this is a wonderful idea. I'd like to see the obsolete APIs start to be wrapped inside an ifdef, maybe something like NETSNMP_INCLUDE_DEPRECATED_APIS. Naturally, it would default to being defined in the beginning. Those wanting to reduce memory footprint a bit could turn it off. Eventually, it could default to off. -- 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: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
