Re: [boost] surveying async network io libraries

From: Cliff Green (cliffg_at_[hidden])
Date: 2005-08-11 17:31:02

>>> 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