Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On 10/23/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > On Sun, Oct 21, 2007 at 02:00:38PM +0200, Chris Brody-GMail wrote: > [...] > > Thank you guys for the attention to the issue. Small questions: 1. > > would the evbuffer & bufferevents still be part of the libevent-core, > > or something else? I am working on a C++ interface for this part. > > I'm pretty sure that evbuffer and friends should stay in event-core, [...] Good-that's what I was hoping! > It's not www only: it's http, dns, and rpc. In the future, it might > grow. Right ... I believe the original patch had also made a cleaner separation of these parts for the regression tests. Can this fix be considered as well? Thanks again, CB ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On Sun, Oct 21, 2007 at 02:00:38PM +0200, Chris Brody-GMail wrote: [...] > Thank you guys for the attention to the issue. Small questions: 1. > would the evbuffer & bufferevents still be part of the libevent-core, > or something else? I am working on a C++ interface for this part. I'm pretty sure that evbuffer and friends should stay in event-core, for two reasons: * Unlike HTTP, RPC, and DNS, they're pretty protocol-neutral. * Like event_base, they can be optimized on different platforms in different ways. (Windows, for instance, is begging for an IOCP implementation of bufferevents. I've got one from a student that I want to merge into the next major revision or the one after that, time permitting.) > 2. Could we give "extras" a slightly sexier name such as WWW or > web-server? I do find this to be a valuable part as well, and I am > planning to work on a C++ interface for the HTTP server part in the > future. It's not www only: it's http, dns, and rpc. In the future, it might grow. I'm going to go with the name Niels gave, since it lets me make the changes sooner rather than later. :) yrs, -- Nick Mathewson pgp2u2EZmxbhH.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for--disable-dns, --disable-http, and --disable-bevents
To KISS, do you guys think libevent can use a regular makefile (maybe multiple makefile.platform) instead automake. Just a thought from a Linux newbie developer who doesn't have autoconfig installed in his box and mostly important, only understand makefile. ;-) Thanks guys. Arthur - Original Message - From: "Chris Brody-GMail" <[EMAIL PROTECTED]> To: "Nick Mathewson" <[EMAIL PROTECTED]>; "Niels Provos" <[EMAIL PROTECTED]> Cc: Sent: Sunday, October 21, 2007 8:00 AM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for--disable-dns, --disable-http, and --disable-bevents > On 10/21/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > > On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote: > > > After talking with Nick, I think the solution that makes the most > > > sense is to build three different libraries: > > > > > > - libevent-core which contains only the event loop > > > - libevent-extras which contains DNS, HTTP, etc. > > > - libevent which contains everything for backwards compatibility > > > > > > That should make everyone happy. > > > > Okay! I'll do this in trunk in the next couple of days, assuming that > > nobody objects. > Thank you guys for the attention to the issue. Small questions: 1. > would the evbuffer & bufferevents still be part of the libevent-core, > or something else? I am working on a C++ interface for this part. > > 2. Could we give "extras" a slightly sexier name such as WWW or > web-server? I do find this to be a valuable part as well, and I am > planning to work on a C++ interface for the HTTP server part in the > future. > > > Another issue: We're apparently using the --revision and --version > > arguments to libtool wrong. Our use of --revision means that binaries > > built against one version of libevent need to be rebuilt to use the > > next. Our current non-use f --version-info means that once we fix the > > --revision problem, we'll give linkers the wrong idea about which > > versions of libevent are which. > It seems to me, that this was the equivalent of starting with 0:0:0. > If I read the page right, we could use something like "1:0:1", which > indicates that we have a "new" interface, but we remain backward > compatible with the first version. > ___ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On 10/21/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote: > > After talking with Nick, I think the solution that makes the most > > sense is to build three different libraries: > > > > - libevent-core which contains only the event loop > > - libevent-extras which contains DNS, HTTP, etc. > > - libevent which contains everything for backwards compatibility > > > > That should make everyone happy. > > Okay! I'll do this in trunk in the next couple of days, assuming that > nobody objects. Thank you guys for the attention to the issue. Small questions: 1. would the evbuffer & bufferevents still be part of the libevent-core, or something else? I am working on a C++ interface for this part. 2. Could we give "extras" a slightly sexier name such as WWW or web-server? I do find this to be a valuable part as well, and I am planning to work on a C++ interface for the HTTP server part in the future. > Another issue: We're apparently using the --revision and --version > arguments to libtool wrong. Our use of --revision means that binaries > built against one version of libevent need to be rebuilt to use the > next. Our current non-use f --version-info means that once we fix the > --revision problem, we'll give linkers the wrong idea about which > versions of libevent are which. It seems to me, that this was the equivalent of starting with 0:0:0. If I read the page right, we could use something like "1:0:1", which indicates that we have a "new" interface, but we remain backward compatible with the first version. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On Sat, Oct 20, 2007 at 10:22:27AM -0700, Niels Provos wrote:
> After talking with Nick, I think the solution that makes the most
> sense is to build three different libraries:
>
> - libevent-core which contains only the event loop
> - libevent-extras which contains DNS, HTTP, etc.
> - libevent which contains everything for backwards compatibility
>
> That should make everyone happy.
Okay! I'll do this in trunk in the next couple of days, assuming that
nobody objects.
Another issue: We're apparently using the --revision and --version
arguments to libtool wrong. Our use of --revision means that binaries
built against one version of libevent need to be rebuilt to use the
next. Our current non-use f --version-info means that once we fix the
--revision problem, we'll give linkers the wrong idea about which
versions of libevent are which.
What we need to do in order to use --version-info correctly is
described here:
http://sourceware.org/autobook/autobook/autobook_91.html
Is this something that we're willing to do? If I understand the
documentation correctly, then practice, we'd have to keep 3 numbers:
"Current", "Revision", and "Age". We'd need to note, whenever we do a
new release: whether it adds new interfaces, and whether it breaks
binary compatibility, and then, by cases:
if (the interface changed) {
if (binary compatibility isn't broken)
increment "age";
Increment "current", set "revision" to 0.
} else {
increment "revision";
}
It's a little more bookkeeping, but I believe it would make us play
better with linkers and applications. For more background, see the
thread "Question: Library Naming."
yrs,
--
Nick Mathewson
pgpFaEybGoy1x.pgp
Description: PGP signature
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
After talking with Nick, I think the solution that makes the most sense is to build three different libraries: - libevent-core which contains only the event loop - libevent-extras which contains DNS, HTTP, etc. - libevent which contains everything for backwards compatibility That should make everyone happy. Niels. On 10/2/07, Chris Brody-GMail <[EMAIL PROTECTED]> wrote: > On 10/2/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > > [...] > > > libcurl has developed a good API for its integration with libevent. > > > libcurl project also maintains and develops a very good asynchronous DNS > > > client library, called c-ares (a clone of ares). > > > > > > Could it be a better path to concentrate the community efforts on > > > integration of c-ares and libcurl with libevent and to assist better > > > to applications? > > > > I would love somebody to get c-ares working right with libevent. I > > don't think this is a matter of "concentrating the community efforts", > > however: I think it's a matter of somebody stepping up to contribute > > the right patch to c-ares. > [...] > I am happy to take a look in my free time, despite a lack of > experience with libcurl & c-ares. I hope the HTTP & DNS parts of > libevent can be officially built separately, regardless about where > the source code is kept. > > Due to a lack of "official" RPM, my company is building libevent > ourselves, so I would like to try Christopher's patches to Makefile.am > & configure.in internally and report the results. > > I would like to suggest another idea, to automatically build both a > "full" libevent library and a set of separated libevent parts, until > the next major release. > > Chris > ___ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On 10/3/07, Scott Lamb <[EMAIL PROTECTED]> wrote: [...] > I think the -levent-core -lev-http approach makes sense, but (quoting > Nick Mathewson's email): [...] I hope this will be possible. We actually have one process that only uses "event-core" and another process that also needs "ev-http". > Due to a lack of "official" RPM, my company is building libevent > ourselves, so I would like to try Christopher's patches to Makefile.am > & configure.in internally and report the results. I have made a patch based on the original idea, to patch the automake files and a few tests and uploaded them to: * http://chris.brody.googlepages.com/libevent_ac_cjb_20071002.diff.txt * http://chris.brody.googlepages.com/libevent_test_cjb_20071002.diff.txt However, this does not help us since different processes use different parts. In addition, the original proposal makes a separate evbuffer.h header file. Such modular design is very important for object-oriented programming. For example: http://repo.or.cz/w/eventxx.git ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
Chris Brody-GMail wrote: > I would like to suggest another idea, to automatically build both a > "full" libevent library and a set of separated libevent parts, until > the next major release. +1 I think the -levent-core -lev-http approach makes sense, but (quoting Nick Mathewson's email): > 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? IIRC, Chris Brody's suggestion is the only way to do that, as library dependencies are not transitive in some situations (static libraries, and dynamic libraries some platforms). ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
Nick Mathewson wrote: > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > [...] >> libcurl has developed a good API for its integration with libevent. >> libcurl project also maintains and develops a very good asynchronous DNS >> client library, called c-ares (a clone of ares). >> >> Could it be a better path to concentrate the community efforts on >> integration of c-ares and libcurl with libevent and to assist better >> to applications? > > I would love somebody to get c-ares working right with libevent. I > don't think this is a matter of "concentrating the community efforts", > however: I think it's a matter of somebody stepping up to contribute > the right patch to c-ares. > > The last time I checked, the main problems preventing c-ares from > working optimally with libevent were: > o C-ares had functions to fetch a list of sockets that needed > to be read and written, but no way to make a callback happen when > that list changes. This is fine for select() and poll(), but > Libevent, on the other hand, wants to be told about _changes_ in > socket state via event_add and event_del. > > Fixing this is probably a matter of adding a callback facility to > c-ares. It already exists: struct ares_options options; ... options.sock_state_cb = foo; ... ... = ares_init_options(..., &options, ...|ARES_OPT_SOCK_STATE_CB); > o The only way to tell c-ares about readable/writable sockets was > via a function, ares_process(), that took an fd_set. This is > suboptimal because 1) Libevent wants to alert applications about > one socket at a time, and 2) Libevent is designed for situations > where there are thousands of sockets, and making an fd_set with > thousands of elements gives awful performance. > > Fixing this is probably a matter of adding an alternate way to > invoke functionality of ares_process(). Also exists: void ares_process_fd(ares_channel channel, ares_socket_t read_fd, ares_socket_t write_fd); > > Of course, stuff may have changed since then; these problems may be > solved. Yup. > > (I, _personally_, don't think I could use c-ares for my needs, since I > need DNS server support as well as client support, and I'm under the > impression that c-ares only provides the latter. But the more > libraries that support libevent, the better.) > > yrs, > > > > > ___ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On 10/2/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: > [...] > > libcurl has developed a good API for its integration with libevent. > > libcurl project also maintains and develops a very good asynchronous DNS > > client library, called c-ares (a clone of ares). > > > > Could it be a better path to concentrate the community efforts on > > integration of c-ares and libcurl with libevent and to assist better > > to applications? > > I would love somebody to get c-ares working right with libevent. I > don't think this is a matter of "concentrating the community efforts", > however: I think it's a matter of somebody stepping up to contribute > the right patch to c-ares. [...] I am happy to take a look in my free time, despite a lack of experience with libcurl & c-ares. I hope the HTTP & DNS parts of libevent can be officially built separately, regardless about where the source code is kept. Due to a lack of "official" RPM, my company is building libevent ourselves, so I would like to try Christopher's patches to Makefile.am & configure.in internally and report the results. I would like to suggest another idea, to automatically build both a "full" libevent library and a set of separated libevent parts, until the next major release. Chris ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
On Tue, Oct 02, 2007 at 09:35:48AM +0200, Robert Iakobashvili wrote: [...] > libcurl has developed a good API for its integration with libevent. > libcurl project also maintains and develops a very good asynchronous DNS > client library, called c-ares (a clone of ares). > > Could it be a better path to concentrate the community efforts on > integration of c-ares and libcurl with libevent and to assist better > to applications? I would love somebody to get c-ares working right with libevent. I don't think this is a matter of "concentrating the community efforts", however: I think it's a matter of somebody stepping up to contribute the right patch to c-ares. The last time I checked, the main problems preventing c-ares from working optimally with libevent were: o C-ares had functions to fetch a list of sockets that needed to be read and written, but no way to make a callback happen when that list changes. This is fine for select() and poll(), but Libevent, on the other hand, wants to be told about _changes_ in socket state via event_add and event_del. Fixing this is probably a matter of adding a callback facility to c-ares. o The only way to tell c-ares about readable/writable sockets was via a function, ares_process(), that took an fd_set. This is suboptimal because 1) Libevent wants to alert applications about one socket at a time, and 2) Libevent is designed for situations where there are thousands of sockets, and making an fd_set with thousands of elements gives awful performance. Fixing this is probably a matter of adding an alternate way to invoke functionality of ares_process(). Of course, stuff may have changed since then; these problems may be solved. (I, _personally_, don't think I could use c-ares for my needs, since I need DNS server support as well as client support, and I'm under the impression that c-ares only provides the latter. But the more libraries that support libevent, the better.) yrs, -- Nick Mathewson pgpBiLf11g4pH.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
Larry, On 10/2/07, Larry Lewis <[EMAIL PROTECTED]> wrote: > > 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. > Y are bringing a good point.. libevent is a great library for events demultiplexing, and I like it a lot. I would also doubt the addition of HTTP and DNS client stacks to the library itself, whereas they can be very good as the examples and testing applications. libcurl has developed a good API for its integration with libevent. libcurl project also maintains and develops a very good asynchronous DNS client library, called c-ares (a clone of ares). Could it be a better path to concentrate the community efforts on integration of c-ares and libcurl with libevent and to assist better to applications? For example, curl-loader is using libevent for demultiplexing and HTTP and FTP client stacks of libcurl to create a client side HTTP/HTTPS/FTP/FTPS testing framework (disclaimer - I am a maintainer of curl-loader, and, therefore, biased). Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... http://curl-loader.sourceforge.net A web testing and traffic generation tool. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
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
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 pgpuRBeHeKHkv.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
+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. Otherwise, I'm using libevent as the basis for a set of single-threaded C++ class libraries (sockets and timers and such), and so far, I'm extremely happy with it. Thanks for great library. Larry - Original Message From: Wouter Wijngaards <[EMAIL PROTECTED]> To: Christopher Layne <[EMAIL PROTECTED]> Cc: libevent-users@monkey.org Sent: Monday, October 1, 2007 8:11:36 AM Subject: Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents -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 ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
-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
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
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
Re: [Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
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.
On 9/26/07, Christopher Layne <[EMAIL PROTECTED]> wrote:
> $ ./configure --help
> [...]
> Optional Features:
> [...]
> --enable-dnsbuild with support for dns layer [default=yes]
> --enable-http build with support for http layer [default=yes]
> --enable-beventsbuild with support for buffer events [default=yes]
>
> Changes:
>
> 1. This required me to move buffer_* and evbuffer_* function declarations
> that were in event.h to a new file, evbuffer.h. Also, it looks like
> buffer.c contains ev_buffer_* functions and evbuffer.c contains
> buffer_* functions. This was like this before so I just tried to keep
> things consistent overall when creating a new header file and went with
> evbuffer.h. The flip-flop can be changed later. Also added evbuffer.h include
> to various http and bufferevents specific modules/headers that required them.
>
> 2. This required creating test/regress_buffer.c and moving bevents
> regress specific code into that module. Calls to higher level regress
> suite collection functions are conditionally ifdef'd via HAVE_EVENT_DNS,
> HAVE_EVENT_HTTP, etc. (which configure takes care of).
>
> 3. In both cases of above, the actual conditional building of modules
> is handled via ifdef's within Makefile.am that configure takes care of.
>
> 4. Modified configure.in to not bother doing Fortran, C++, or ObjC specific
> tests. Libtool likes to try it's own checks as well, but I just redefined
> those with simple null macros.
>
> 5. Throughout this all: substantially increased my derision for GNU auto*
> tools.
>
> Pros:
>
> 1. Significantly smaller libevent library footprint but the ability to
> include everything normally.
> 2. Default, nothing changes, all API layers are enabled per normal.
> 3. Couple of useful macros added to configure.in which should make adding
> any other enable/disable and build checks quicker.
>
> Cons:
>
> 1. http code is highly dependent on bufferevents code. As such, one cannot
> use "--enable-bufferevents=no" w/ "--enable-http=no". If bufferevent code
> is disabled, http code must be disabled.
> 2. rpc code (which AFAICT is regress testing specific) is tied with http
> code and shares the same characteristics of above.
>
> Builds+size+make verify checks:
>
> $ set=( "--disable-none" \
> "--disable-dns" \
> "--disable-http" \
> "--disable-dns --disable-http" \
> "--disable-bevents --disable-http" \
> "--disable-bevents --disable-http --disable-dns" ); \
> a=${#set[*]}; i=0; while [[ $i -lt $a ]]; do f="${set[i++]}"; echo $f; \
> (./configure $f && make clean && make) 1>/tmp/error.out 2>&1 \
> || (cat /tmp/error.out && break); \
> size .libs/libevent.so; \
> make verify 2>&1 | egrep FAIL && break; \
> printf "\n"; done
>
> --disable-none
>textdata bss dec hex filename
> 6711511206904 75139 12583 .libs/libevent.so
>
> --disable-dns
>textdata bss dec hex filename
> 4880410406328 56172db6c .libs/libevent.so
>
> --disable-http
>textdata bss dec hex filename
> 45589 840 708 47137b821 .libs/libevent.so
>
> --disable-dns --disable-http
>textdata bss dec hex filename
> 26603 728 132 274636b47 .libs/libevent.so
>
> --disable-bevents --disable-http
>textdata bss dec hex filename
> 37882 744 704 3933099a2 .libs/libevent.so
>
> --disable-bevents --disable-http --disable-dns
>textdata bss dec hex filename
> 18969 628 128 197254d0d .libs/libevent.so
>
>
> This patch is 50k, but is mostly just -+ of moving buffer-specific code from
> one file to another and the such. Attached as bzip2 here, and also raw at
> this url: http://www.anodized.com/~clayne/libevent.2007092600.diff
>
> -cl
>
> ___
> Libevent-users mailing list
> Libevent-users@monkey.org
> http://monkey.org/mailman/listinfo/libevent-users
>
>
>
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
[Libevent-users] [PATCH] Add autoconf/make functionality for --disable-dns, --disable-http, and --disable-bevents
$ ./configure --help
[...]
Optional Features:
[...]
--enable-dnsbuild with support for dns layer [default=yes]
--enable-http build with support for http layer [default=yes]
--enable-beventsbuild with support for buffer events [default=yes]
Changes:
1. This required me to move buffer_* and evbuffer_* function declarations
that were in event.h to a new file, evbuffer.h. Also, it looks like
buffer.c contains ev_buffer_* functions and evbuffer.c contains
buffer_* functions. This was like this before so I just tried to keep
things consistent overall when creating a new header file and went with
evbuffer.h. The flip-flop can be changed later. Also added evbuffer.h include
to various http and bufferevents specific modules/headers that required them.
2. This required creating test/regress_buffer.c and moving bevents
regress specific code into that module. Calls to higher level regress
suite collection functions are conditionally ifdef'd via HAVE_EVENT_DNS,
HAVE_EVENT_HTTP, etc. (which configure takes care of).
3. In both cases of above, the actual conditional building of modules
is handled via ifdef's within Makefile.am that configure takes care of.
4. Modified configure.in to not bother doing Fortran, C++, or ObjC specific
tests. Libtool likes to try it's own checks as well, but I just redefined
those with simple null macros.
5. Throughout this all: substantially increased my derision for GNU auto*
tools.
Pros:
1. Significantly smaller libevent library footprint but the ability to
include everything normally.
2. Default, nothing changes, all API layers are enabled per normal.
3. Couple of useful macros added to configure.in which should make adding
any other enable/disable and build checks quicker.
Cons:
1. http code is highly dependent on bufferevents code. As such, one cannot
use "--enable-bufferevents=no" w/ "--enable-http=no". If bufferevent code
is disabled, http code must be disabled.
2. rpc code (which AFAICT is regress testing specific) is tied with http
code and shares the same characteristics of above.
Builds+size+make verify checks:
$ set=( "--disable-none" \
"--disable-dns" \
"--disable-http" \
"--disable-dns --disable-http" \
"--disable-bevents --disable-http" \
"--disable-bevents --disable-http --disable-dns" ); \
a=${#set[*]}; i=0; while [[ $i -lt $a ]]; do f="${set[i++]}"; echo $f; \
(./configure $f && make clean && make) 1>/tmp/error.out 2>&1 \
|| (cat /tmp/error.out && break); \
size .libs/libevent.so; \
make verify 2>&1 | egrep FAIL && break; \
printf "\n"; done
--disable-none
textdata bss dec hex filename
6711511206904 75139 12583 .libs/libevent.so
--disable-dns
textdata bss dec hex filename
4880410406328 56172db6c .libs/libevent.so
--disable-http
textdata bss dec hex filename
45589 840 708 47137b821 .libs/libevent.so
--disable-dns --disable-http
textdata bss dec hex filename
26603 728 132 274636b47 .libs/libevent.so
--disable-bevents --disable-http
textdata bss dec hex filename
37882 744 704 3933099a2 .libs/libevent.so
--disable-bevents --disable-http --disable-dns
textdata bss dec hex filename
18969 628 128 197254d0d .libs/libevent.so
This patch is 50k, but is mostly just -+ of moving buffer-specific code from
one file to another and the such. Attached as bzip2 here, and also raw at
this url: http://www.anodized.com/~clayne/libevent.2007092600.diff
-cl
libevent.2007092600.diff.bz2
Description: Binary data
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
