[Libevent-users] [PATCH] Add callback for raw read/write

olla, I dont know what the process for submitting patches here, but this is against version 1.4.9. This makes it easier to integrate libraries that provide their own read/write functions (such as openssl). Example usage would be something like: - static size_t myrcb(int fd, void *buf,

Re: [Libevent-users] [PATCH] Add callback for raw read/write

On Thu, Feb 19, 2009 at 5:09 AM, jamal h...@cyberus.ca wrote: This makes it easier to integrate libraries that provide their own read/write functions (such as openssl). I haven't looked at the patch, but I'm a little skeptical of a one-size-fits-all approach to integrating things like openssl.

Re: [Libevent-users] [PATCH] Add callback for raw read/write

On Thu, 2009-02-19 at 05:35 -0800, Dan Kegel wrote: I haven't looked at the patch, sufficient to look at the simple example usage shown in the email but I'm a little skeptical of a one-size-fits-all approach to integrating things like openssl. As the openssl faq says, you can't just call

Please check svn trunk before you write feature patches [was Re: [Libevent-users] [PATCH] Add callback for raw read/write]

On Thu, Feb 19, 2009 at 08:09:18AM -0500, jamal wrote: olla, I dont know what the process for submitting patches here, but this is against version 1.4.9. This makes it easier to integrate libraries that provide their own read/write functions (such as openssl). Hi, Jamal! Thanks for the

Re: Please check svn trunk before you write feature patches [was Re: [Libevent-users] [PATCH] Add callback for raw read/write]

Hi Nick, On Thu, 2009-02-19 at 10:33 -0500, Nick Mathewson wrote: Thanks for the patch, but the Libevent 2 dev series (currently calling itself 1.4.99) handles evbuffers and bufferevents significantly differently. (Old code still works, but the implementation is more efficient.) We're

[Libevent-users] dumb question

I hope i come out sound patronizing or putting down the good work done in libevent. Is libevent trying to be too many things? I love the all-things-IO libevent provides; i guess buffer events are a natural evolution path - but why all the DNS or HTTP stuff? whats next? Is the end goal to become

[Libevent-users] Re: dumb question

On Thu, 2009-02-19 at 11:13 -0500, jamal wrote: I hope i come out sound patronizing or putting down the good work done in libevent. Sorry: I meant quiet the opposite ;- i.e hope i dont come out sounding patronizing. cheers, jamal ___ Libevent-users

Re: [Libevent-users] dumb question

On Thu, Feb 19, 2009, jamal wrote: I hope i come out sound patronizing or putting down the good work done in libevent. Is libevent trying to be too many things? I love the all-things-IO libevent provides; i guess buffer events are a natural evolution path - but why all the DNS or HTTP

Re: [Libevent-users] dumb question

jamal wrote: Is libevent trying to be too many things? I love the all-things-IO libevent provides; i guess buffer events are a natural evolution path - but why all the DNS or HTTP stuff? The DNS and HTTP stuff is there so people don't have to constantly re-invent those tasks themselves.

Re: [Libevent-users] dumb question

Hello all, if with async io is meant doing native async disc / file io, then there already is code that integrates with libevent-2.0. Recently, Valery Kholodkov and myself did some work in this direction. The latest version you can find in Valery's git tree right here:

Re: [Libevent-users] dumb question

On Thu, Feb 19, 2009, Nick Mathewson wrote: If I understand correctly, Adrian, you also think that bufferevent-ish stuff should have API-separation from the event-ish stuff (which I believe in) and that it should go into a separate library from libevent_core (which I don't agree with, but I