Don G wrote: Hi Don,
[...] So, yes, I do think we need this layer or one much like it. And it must be much lower level than <iostream>. The abstraction I proposed
I think socket streams are no competitor anyway. An ACE-like library and socket streams can be both built on top of level 0 so they both live in level 1. While socket streams offer blocking and maybe non-blocking I/O using the familiar stream interface the other packages in level 1 should have clear goals, too. The package in http://www.highscore.de/boost/net/packages.png I called "ace" was introduced after my discussion with Michel. We talked about acceptor-connector pattern and service handlers, and I think these concepts can help developers using the network without any idea of sockets and how they work. That said I am trying to find out what your library offers to understand if it belongs to the same package which is called "ace" right now. Or your library has different goals which means we need another package in level 1 or even worse a new level. In the end the network library can and should consist of different packages to meet different requirements but it should be very clear to library users which requirements are met by each package.
[...] I have acceptor in my proposal, but connector didn't seem (to me) to be an entire class/object. I have an address object as the Abstract Factory for a stream object, which is similar to a connector concept except that the connection process begins with a method on the stream object. In other words, the stream is created in an unconnected state and it is that stream that we want to connect. This felt like a much better fit to the problem at hand (again, to me<g>).
As far as I understand the acceptor-connector pattern the idea is that a connector behaves like an acceptor. This means both of them are factories producing connected streams. Most network developers (who know Berkeley sockets) will probably create an acceptor based on accept() and a connector based on connect(). The acceptor will work as a factory but the connector can probably be used only once to create one connected stream. This is what I did in http://www.highscore.de/boost/net/basic.png and comes close to the C API. If we think of unexperienced developers who don't know any sockets they will probably be happy if the connector behaves like the acceptor as they wouldn't understand the difference. Regarding the acceptor and connector your library seems to be close what I made up in the class hierarchy and therefore would belong to level 0.
[...] My goal is to iron out a behavior contract that satisfies various possible and desired implementations, so that a library user can know what are safe and portable practices. One could say that the sockets API does this, but there are two central issues: one cannot create a new type of socket (to layer protocols); not all forms of I/O completion are portable.
I am surprised to read this! The socket API - the so-called level 0 - must and will be portable. It should be possible to derive classes from socket and create new types. And all four types of I/O must be supported in level 0, too. What kind of problems do you see here?
[...] The layer is conceptually complete (or should be made so by adding new abstractions). The only reasons I see for going around the layer I propose would be: use of platform-specific features or performance.
If the network library should support platform-specific features we should indeed add another package to http://www.highscore.de/boost/net/packages.png. This package would be optional. However it would be nice if classes from this package would collaborate somehow with classes from the other non-optional packages of the network library. The non-optional packages would provide a default implementation and library users could use optimized classes from the optional package depending on the platform they are using.
[...] I hope I have answered your questions.
Yes, thank you very much! Sorry to have some new questions now. :) Boris