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
http://www.highscore.de/boost/net/basic.png 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
http://www.highscore.de/boost/net/packages.png. 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
immediately."
* 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
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket):
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.
Boris
