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
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
rthur
- 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/mak
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
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.
> - libev
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 mak
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".
>
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
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)
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 libra
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 p
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 i
event 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
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 h
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
-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
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 ma
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
$ ./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 requ
19 matches
Mail list logo
