RE: [boost] Re: Sockets - what's the latest?

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-02-14 11:38:44

...various comments about ACE from various authors.... 
> >> [...]
> >> How about borrowing ideas from ACE, but implementing them in
> >> modern C++?  Or has that been discussed already?  Or is the ACE
> >> framework too obsolete-C++ to be a useful design?
> >
> > We probably should at least consider ACE ideas. But I guess this would
> > require several of us to dig into ACE which would delay further a Boost
> > socket library. However ACE could be a valuable investment?

I have some pretty deep experience with using ACE.  ACE has many
excellent design constructs.  It uses a mix of Object Oriented 
and template approaches.  In fact, it was using policy-based 
design before it became 'popular'.  One example of good design
is the use of a portability layer (ACE_OS) to wrap up the 
variations in the C API's.  This greatly simplifies porting.
I think that we are (and should continue) to be evaluating 
the elements of ACE and how the constructs there might be 
useful in the boost libraries.  Note that the current 
proposal borrows much from ACE design constructs:
portability layer, acceptor, connector, and 
multiplexor (reactor in ACE).

That said, ACE is very large and quite difficult to learn.
This isn't hard to understand since it encompasses constructs for 
network programming, threads, and more.  It took 2 300 page books 
just to just scratch the surface. The partitioning at the source code 
level is weak since everything basically resides in /ace. I see this 
as a major impediment to using ACE and is to be avoided by prospective
boost libraries.

In addition to size, the ACE implementation leaves some other things 
to be desired.  It is over 10 years old -- ported to all sorts 
of platforms.  The implementation is a literal MACRO hell.  ACE 
doesn't take as much advantage of the standard library as we 
would expect of a boost library.  It also doesn't leverage
C++ features like namespaces and exceptions as we just expect 
of boost libraries.  So I agree that we should look there for
major design elements and not implementation approaches.

Some other things about ACE: It has been ported to a myriad of 
platforms and is used extensively in commercial application 
development because of it's open licensing and general utility, 
portability, and the open source Object Request Broker (TAO) 
which is built on top.  ACE has been developed by literally 
hundreds of volunteers and has had the benefit of commercial 
funding.  In short, I find it unlikely that in the near term 
any set of boost libraries will replace it for  someone that 
is interested in writing a network server.

And I don't think that we should have 'competing' or 'replacing'
ACE for all applications as our goal. Rather, I think we focus first
on what is needed to do basic network programming -- especially for
'simple tasks'.  For example, I need a client to go retrieve
a web page or send some information to a server.  These kinds of
tasks are now extremely common and needing the entire ACE 
library just to do this is just wacky. 

So in summary, I think we should focus the Boost.Socket effort
on what is currently described as 'level 1 - OS platform layer'
and 'level 2 - basic connectivity layer' leaving multiplexing
for later.  I'm sure this will be controversial with some, but
it seems to me that this is the only reasonable approach for a 
boost library daring to tread into a complex domain.  I think 
that we need to look at boost::thread and boost::filesystem as 
examples of this approach.  

Dave A wrote:
> >From what I've heard, the ACE architecture is highly interdependent,
> with everything depending on everything else.  There /might/ be
> something to be gained by looking at its interface, but I would
> approach it with caution.

I don't think it is as interdependent as it might appear at first since
the overall design is actually quite structured.  However, since it
is packaged as a single library you are pretty much stuck with the
whole enchilada.

Jeff