<html><head><style type="text/css"></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">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.  <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ---- From: Nick Mathewson <nickm@freehaven.net> 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 <div>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 </div></div> </div></div></body></html>