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. I also believe that non-blocking is an I/O only thing; it is not needed for connect or accept.
* It should be possible to switch between I/O models at runtime (which means you have one socket class supporting all I/O models instead of different socket classes each of them supporting only one I/O model).
Perhaps "switch" isn't the best term. On a per-operation basis, the user should chose between styles.
* 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). I think a common pattern for async behavior should be agreed upon and if some implementation details turn out to be reusable, that's a good happenstance. My prediction is that on Unix platforms, there will be more to reuse between sockets, pipes, files, etc.. On Windows, there will be little.
* There should be an asynchronous design pattern which should be used by all Boost libraries which support asynchronous operations.
I agree completely on this one :)
* 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.
* On a high level there should be I/O streams support.
I agree again ;)
As far as I can see from all the discussions that's what we agree on. There have been some ideas like event handlers and dispatchers but I am not sure where to put them - have a look at http://www.highscore.de/boost/net/packages.png please (which is also in the Wiki page). This is the overall architecture of the network library. If you want me to change or add something please tell me.
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. The philosophy I have on this may be out of sync with some (pun intended), but IMHO, we need to hash over the philosophy as much as anything. We have a lot of folks that are very comfortable with the sockets interface, but I don't believe that exposing its idiosyncrasies is the right approach. Everyone that writes sockets code runs into the same problems, and solves them in varying degrees 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. ;) Best regards, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/