Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at