On Fri, Feb 20, 2009 at 01:35:07AM +0900, Adrian Chadd wrote: [...] > 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.
I definitely like the idea of enforced API boundaries, and the protocol specific code is already built as a separate library (libevent_extra) so that people who only want the central event code can just link against libevent_core. 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). 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. yrs, -- Nick _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
