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