Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-04-17 11:08:24

Michel André wrote:
> [...] It's all in a name ;) . Then I don't think they should be called
> connector and acceptor in level 0 since I was associating it to the
> patterns in POSA2 which I guess a lot of people are familiar with. And
> if we are going to implement these in level 1 it might be confusing to
> have the names with a different implementation in level0. I also think
> there are a lot of good ideas to use from POSA2 and ACE.

Agreed. In the beginning acceptor and connector in were called server and client
until someone complained. Now I also like acceptor/connector better than
server/client but if they remind developers of the acceptor-connector
pattern that's no good. However I don't know any better name in the moment -
if you have an idea please tell me. :)

However I took over your ideas about ACE and updated the package diagram at If we forget about the two
yellow packages for a moment:
* The red package belongs to level 0. I changed the name and now call it
berkeley to emphasize that this package contains a C++ API of what is known
to many programmers as Berkeley sockets. The idea of this package is that
network developers who glance at the C++ network library recognize many
concepts and switch over. They should look at the documentation, see a class
socket and think: "I know everything about sockets - I can use these classes
* The blue packages belong to level 1. I introduced a new package called ace
because of the acceptor-connector pattern which is used in ACE. This package
is for network programmers who look at the documentation, see
application-level concepts and think: "I can connect my application to the
network without understanding sockets."
* The other blue package called iostream is for network programmers who know
std::iostream and would like to use something similar for synchronous I/O on
the network. As someone proposed it would be nice to implement a streambuf
class for network operations.

The package names were made up on the spot - there are probably better ones.
The design however comes close to what we had already in the Wiki (see
There are two levels described - one as a wrapper for the C API (the
berkeley package), the other one for connector, acceptor and data connection
(our ace package). BoostSocket/Streams is the iostream package in the
diagram. The multiplexing library I once proposed myself is one of the four
supported I/O models which can be used in level 0 (there must be something
similar to select()) and in level 1 (if we follow ACE there will be
something like the Reactor class).

Any comments? I'd be happy to hear some ideas which might be missing in the
big picture.


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