-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I'll speak up again, and say that I think the features do not belong in the library. It is feature bloat - for libevent - but perhaps not in their own library, where they would be enriched features built upon libevent. My argument was not based on 30Kb library, but on lines of code, and thus also code complexity and bugs, that it has. More code means more maintenance, luckily Nick is helping you now. Best regards, Wouter Christopher Layne wrote: > On Thu, Sep 27, 2007 at 08:31:32AM -0700, Niels Provos wrote: >> Hi Christopher, >> >> I am not sure if this is necessarily the right way to go for a >> library, esp if it can impact backwards compatibility for >> bufferevents. As for reducing the size of the library, do you really >> think that 30K make a difference these days? >> >> Niels. > > It won't impact backwards compatibility unless someone explictly removed > support for bufferevents. Additionally, where do we draw the line on > what makes a difference these days, when it comes down to it? 1M? 2M? > On a typical *bsd/linux platform, I agree, it won't make a significant > difference at the end of the day. I also agree that using autoconf and > automake to manipulate things is a hack in itself (they always feel like > a hack unfortunately). I also don't know how many people are using > libevent on smaller platforms (embedded, etc) but I thought that perhaps > it could have had some kind of benefit. > > Part of my impetus was based on this post which directly identifies some > concerns and ideas: > > -- >>From [EMAIL PROTECTED] Thu Feb 8 11:31:50 2007 > From: [EMAIL PROTECTED] (Niels Provos) > Date: Thu Feb 8 11:31:53 2007 > Subject: [Libevent-users] [Patch] Third attempt: Add support for DNS > servers to evdns.c (This time with regression tests!) > In-Reply-To: <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Status: RO > Content-Length: 720 > Lines: 16 > > On 1/30/07, Wouter Wijngaards <[EMAIL PROTECTED]> wrote: >> Please, why put these really big http and dns protocols into an event >> handling library? I would prefer libevent to stay focused on providing >> portable select() and alternatives wrappers. >> >> The http and evdns are pretty big compared to the rest of libevent. They >> can be put in their own library(or -ies) perhaps? Some sort of >> libevent-driven application support? > > There has been some talk about libevent creating two different > libraries during compile. One would be the traditional libevent and > the other one would layer on top of it. Still thinking about the > best way of doing this, but you are not the only one with concerns > about bloat. > > Niels. > -- > > So based on that, I went and wrote a patch. > > -cl > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHAOP4kDLqNwOhpPgRAts5AKCNRbr//JnAqLV2OMmhtp1SPy2HjQCfdrVL 85SGZbpBvUMo3OhKpvaUjyU= =603c -----END PGP SIGNATURE----- _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
