Re: [Libevent-users] To upgrade or not to upgrade - that is the question

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

On Thu, Aug 19, 2010 at 04:05:32PM -0400, Nick Mathewson wrote:
> On Wed, Aug 11, 2010 at 3:16 PM, Thor Lancelot Simon <tls@xxxxxxxxx> wrote:
> > On Tue, Aug 10, 2010 at 04:27:47PM -0700, Gilad Benjamini wrote:
> >>
> >> What are the major benefits of 2.0 ?
> >
> > From my point of view, a lot of convenience code was added which many
> > large programs already written to the libevent 1.4 APIs would already
> > have, some APIs were cleaned up, and the library was bloated almost
> > beyond all recognition.
> 
> Sorry to hear it; I've heard this offline from a couple of other
> people too.  The APIs do not seem bloaty to me, but I suppose that any
> API that your projct doesn't need is necessarily bloat to you.
> 
> As it stands, there's nothing stopping you from just linking with the
> libevent_core library, and omitting most of the stuff you don't like.
> The protocol stuff is all in libevent_extra, and the ssl support is in
> libevent_openssl.  Those parts you can just not use if you don't want
> or need them.


FWIW this is what OpenBSD now do with 1.4 - we include "core" libevent
in the base system and relegate the "extra" parts (used by nothing in
base) to the ports system.

> 
> The bufferevent code stays in libevent_core (since it was there in
> 1.4.x) but nothing inherently stops libevent_core from splitting in
> some future release, maybe into a libevent_base and a
> libevent_buffered or something.  If you're building for a
> very-low-memory embedded environment, you can also chop out some more
> code with --disable-thread-support and --disable-malloc-replacement
> and --disable-debug-mode.
> 
> I'm amenable to making the libraries even more fine-grained in 2.1 or
> later if somebody else wants to do the refactoring work on that, or
> adding configure flags to disable API components (e.g.,
> --disable-bufferevents, --disable-listener) if people would find that
> useful.  The splitting could be a bit tricky, though, since old code
> that linked with -levent or -levent_core would need to keep working.

I haven't done much with 2.x, but personally a two way core/extra split
seems just fine. IMO splitting things into a twenty pieces or adding a
dozen --disable-foo options just makes things confusing and hard work
for developers, packagers and users.

It isn't as if libevent is so huge that anyone with truly specialist
needs couldn't butcher it up themselves easily enough.

> 
> I'm afraid I don't see the point of splitting the source distribution,
> though.  What would be gained by that, other than having less source
> to download?
> 
> -- 
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.