ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. ... Yes, but I think many boost users are looking for something simpler as well. ....
Also, Boost users are looking for something that plays well with the C++ Standard Library and TR1. ACE goes its own way. For example, ACE directory iterators aren't anything like STL iterators. That makes ACE less attractive to some users.
Yes, definitely! ACE is an excellent framework, but was designed and implemented for an early 1990's average C++ / OO programmer mentality. I'm assuming much of that was due to when ACE was originally designed, and part of it was due to supporting many "flavors" of C++ (and the standard library) during the mid 90's. I've been using ACE heavily for over a year now, and my list of pros and cons: Pros: o Support for a very large number of platforms o Excellent and powerful implementation of many useful networking related patterns o Nicely extensible framework, for many purposes o Covers a lot of useful, practical functionality o Generally well tested, robust Cons: o The C++ design and usage is not modern, which has many far-reaching implications - no interoperability with standard library, interface design is affected (e.g. it was designed to not use exceptions, resulting in "two stage object construction", in-out parameters with int error returns, etc), use of inheritance where templates would be more suitable (in many places). o The documentation is either too high-level, or not complete. The books written on ACE cover the architecture and general usage very well, but (obviously) can't cover every detail or use case. The Doxygen is useful in some places, and totally useless in others (here's an example I just looked at - "length() - get the length of the message; "size() - get the number of bytes in the top-level <Message_Block>", both of which are separate and distinct, and only understandable from reading the books). o Despite my reluctance to read code, sometimes the only way I've been able to understand what was going on (and what was not working right) was to read the code. Well designed libraries should rarely (or never) require reading the implementation code to understand semantics. o There is not always a clear separation between what is extensible and should be customized by the application / user, and what is not (partly a documentation issue, partly a design issue). o There are too many methods that provide access to internals - i.e. not enough logical encapsulation. There's probably a good reason for each one, but the result is a multitude of methods on almost all classes, many of which have no obvious and direct use. I'm very much looking forward to a well-designed event multiplexor and a set of lower-level network / socket interfaces in Boost. I've offered (and am still offering) to assist within the constraints of my time, either on implementation (although I can only provide limited OS expertise), or general design (I can probably offer more help here). It's good to see more and more momentum and actual offerings start to appear in this realm ... Cliff