[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 the one stop shop for all protocols (like python twisted)? I know i dont have to use or compile all the goodies, but would it not make more sense to keep the protocol processing engines as a separate library that uses libevent (or for that matter whatever the competition is)? cheers, jamal ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/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 stuff? whats next? Is the end goal to become the one stop shop for all protocols (like python twisted)? I know i dont have to use or compile all the goodies, but would it not make more sense to keep the protocol processing engines as a separate library that uses libevent (or for that matter whatever the competition is)? I brought this up with Nick a couple weeks ago when we bumped into each other. I raised the possibility of breaking out the non-event code into separate libraries with enforced API boundaries. We were talking about various directions 2.0 can go in (in the context of doing sensible async IO that will scale under both windows and unix, given their differences of opinion in APIs :) but Nick's design goals differ slightly from my ideals. Adrian ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
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. How often do you connect to a remote host without doing DNS lookups? From another perspective, another completely different library for asynchronous I/O - Boost.Asio - also provides asynchronous resolver functions, because the author of that library had pretty much exactly the same conclusion. For HTTP... well, the doxygen on the subject seems pretty self-explanatory: As libevent is a library for dealing with event notification and most interesting applications are networked today, I have often found the need to write HTTP code. The following prototypes and definitions provide an application with a minimal interface for making HTTP requests and for creating a very simple HTTP server. The server software I've written that *didn't* include an embedded web server for management was being moved in that direction to meet the needs of the operational staff; it's just part and parcel of servers these days. Right now I'm using Boost.Asio instead of libevent (probably better if you're working in C++, but not an option in C), but because of that I'm having to do work that libevent provides out of the box. whats next? What other protocols or services are commonly required by virtually every client, or virtually every server? Is the end goal to become the one stop shop for all protocols (like python twisted)? I think the end goal is to be a useful library for writing clients and servers that want to do I/O asynchronously. I know i dont have to use or compile all the goodies, but would it not make more sense to keep the protocol processing engines as a separate library that uses libevent (or for that matter whatever the competition is)? It could make sense, but what is the benefit to the separation? How many people using libevent will never use evdns or evhttp? -- Matthew Weigel hacker unique idempot . ent ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
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: http://github.com/vkholodkov/libevent/tree/valery-master . What I can say is, that the linux native AIO was stable with several long-running tests ( 300mb/s for longer than 1 day) even in multi-threaded environments. I am not up to date with the latest libevent developments @ trunk, so please just ignore this email if it might prove redundant! Martin Adrian Chadd wrote: 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 stuff? whats next? Is the end goal to become the one stop shop for all protocols (like python twisted)? I know i dont have to use or compile all the goodies, but would it not make more sense to keep the protocol processing engines as a separate library that uses libevent (or for that matter whatever the competition is)? I brought this up with Nick a couple weeks ago when we bumped into each other. I raised the possibility of breaking out the non-event code into separate libraries with enforced API boundaries. We were talking about various directions 2.0 can go in (in the context of doing sensible async IO that will scale under both windows and unix, given their differences of opinion in APIs :) but Nick's design goals differ slightly from my ideals. Adrian ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
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 don't feel too strongly about). I think its fine if they're in the same project, but I don't think they should be sharing library space or header files. That way you can be 100% sure that stuff doesn't depend on other stuff unexpectedly - you'll get compile / link errors. So you'd have libevent_core, libevent_dns, libevent_http, etc, etc. The remaining question here is whether (and to what extent) to split non-libevent-core stuff into a separate source package. I don't feel strongly here either; there are arguments for keeping it in one source package and arguments for splitting it. Personally, I think it's one of those bikeshed issues whose accessibility garners it attention beyond its actual impact. Probably we should revisit it after Libevent 2.0 is out; there is enough architectural stuff slated for 2.0 already IMO. I'm happy to wait for post-2.0 to discuss this stuff further. I don't have enough time to discuss it now. :) adrian ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
