The approach I've seen most often is to mark functions as deprecated and wait for a major release with expected API breakages to actually remove them. I doubt the inclusion of http and dns will be a deal-breaker for anyone, but if this is a sign of more and more code built on top of libevent to be included in the core library, it may discourage porting and usage.
----- Original Message ---- From: Nick Mathewson <[EMAIL PROTECTED]> To: libevent-users@monkey.org Sent: Monday, October 1, 2007 7:20:04 PM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents On Mon, Oct 01, 2007 at 03:46:42PM -0700, Larry Lewis wrote: > +1 for the features not belonging in the library. I'd recommend > moving those features out into supporting libraries > (libevent-http/libevent-dns?) or even just using them as samples. > Most users would probably end up tweaking the http code anyways, in > my opinion. Here's an updated excerpt from the mail I sent Niels back in February, the last time people were talking about this: Niels wrote: > BTW, do you have an opinion about putting the more heavy-weight > libevent stuff into a separate library? Personally, I don't feel very strongly about this, but I'd vote for two libraries built from a single source package, or for two libraries. My reasoning against having only one library is this: I'd like to see the core of libevent get used by more projects, but the larger it becomes, the more work is required to maintain it, and port it to new platforms. I'd like to see the libevent core usable as a back-end by other general-purpose network utility libraries, like apr and glib and Twisted. These libraries already have their own implementations for things like http and rpc, though, and really don't need the ones in libevent. [...] My reason for preferring a single source package is that I'd like the I'd like the extended stuff to be available by default everywhere libevent is available, which is easiest if you have package maintainers start shipping two libraries from one package. (If you create a new source package, that will take more time to see any adoption.) [...] Of course, if you'd rather keep it as one package, I don't think my reasons above are really compelling. Factoring libraries is kind of a bike-shed problem; it's easy to form an opinion, and hard to show that any opinion is significantly better than any other. So, I don't really agree with the original patch either. As a maintainer for an application that uses libevent, it's enough of a pain as it is to tell users "you need to have libevent version X installed on OS Foo; you need libevent version Y on OS Bar, but version Z would be better for performance reasons." It would be inconvenient if we also had to tell users "If your version of libevent was built with certain compilation options, we can't use it. Sorry." So, deleting the functionality: not an option IMO. Moving functionality out of a library is always ugly business: every project that previously depended on the functionality being in the original library will now break, and you'll get a reputation as the kind of project that breaks backward compatibility all the time. Thus, if we're going to try to refactor libevent, we should make very very sure to avoid breaking older programs that are built to use existing libraries. I will not apply any patch for this that breaks backward compatibility. I'm no expert on cross-platform dynamic linkers, but is it feasible (with libtool or otherwise) to arrange things so that we can split libevent into separate libraries (libevent-core, libevent-http, etc), while at the same time ensuring that we don't break old code that searches for a "libevent" library with all the current libevent APIs? yrs, -- Nick Mathewson
_______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
