Don G wrote:
Hi Boris,
I updated
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet
to document why what decisions were made. We have until now:
* The network library should support four I/O models which are known to many programmers as blocking, non-blocking, multiplexing and asynchronous.
Personally, I don't think the multiplexing interface is appropriate or necessary. Essentially the same style can be achieved with multi-threaded async and a boos::function queueing solution. In other words, it is not a group of network objects that is being manipulated. It is a portable dispatcher that gets boost::function<>'s queued to it. It therefore suffers none of the portability issues that a direct wrapper to select would have.
The multiplexing interface can be used in a single-threaded application while the async stuff will be multi-threaded. There might be network developers (like me for example :-) who don't want to synchronize callbacks but just want to build the whole application around a blocking call to select (or any other multiplexing operation).
[...]
* There should be an asynchronous I/O library as other libraries might want to do asynchronous I/O, too.
I don't see this as practical. There is no such thing as async I/O that can be portably described. This means that each kind of async object has to provide the right implementation. Perhaps the scope of portability needs to be stated and agreed upon. When I implemented async pipe I/O on Windows NT/9x, I could not use the same code for I/O as I did with sockets or as I would for files (subtle differences).
Basically I like the idea to have an async I/O library just like std::iostreams which supports synchronous I/O. However I don't know how difficult it is to implement such a library but isn't POSIX aio exactly about this?
[...]
* On a low level the network library should be close to what is known as Berkeley sockets to many programmers.
I think sockets should be hidden. They are not universally used, for example Mac OS9 doesn't and I just assume others exist. They don't have any magical powers; they are just a C abstraction. A C++ abstraction should replace them.
Opinions seem to vary on this. When I once proposed to build a C++ network abstraction with I/O streams I got complaints that it should be possible to use sockets directly in a lower level. Whatever you write the other group will join the thread and complain. :)
[...] We have a couple straw men started (Michel's and mine). Perhaps it is just as good to start just throwing darts at them? I could probably have a full implementation of the interfaces I propose in a small number of weeks (2-3). Having done it once before really helps<g>, but I wanted to get to some common ground on the philosophy before going to that step.
Yes, that's why I am trying to find a design the majority agrees with. If we end up with several network libraries implemented by different people noone will do the effort to understand and compare design decisions.
[...] of sophistication and completeness. A robust solution is not as difficult as some might think. It's certainly easier than getting agreement on philosophical matters. ;)
Absolutely, as we can see. :) Boris