On Wed, 2005-04-27 at 12:32 +0300, Boris wrote:
Iain Hanson wrote:
[...] Not having done much work on iostreams for sockets I thought it would be a little of both but I was not sure. I saw it as a higher layer abstraction that had greater easy of use but probably less flexibility/control.
Whereas Layer 2 has much greater flexibility and control but a greater learning curve if you want/need the more advanced features.
In my opinion this distinction is unclear and subjective.
Of course it is. I have not tried to define in formally. It was just a gut feel that the iostream interface had a greater degree of abstraction and that it would almost certainly be build with the classes from the acceptor connector layer.
As I wrote in http://article.gmane.org/gmane.comp.lib.boost.devel/122421 I agree with Don that there is no need for more than 2 levels right now. Every level and package should be well justified as anything else is confusing. If we can't find good reasons to justify a design we will make it unnecessarily more difficult for library users to understand the whole structure.
Don talks about his proposal as the bottom layer and uses Layer 1 for his proposal and layer 2 for standardised protocols. You use your levels from 0. And there has been a fair amount of confusion between the two of you over numbering for the last couple of months. And btw Hugo Duncan used Layers 1,2 and 3 in his effort and I think on the wiki.
[...] There has always been a need for standard applications protocols such as FTP, Telnet, SMTP, HTTP, etc. But Beman Dawes wrote a set of requirements for a socket library that said something like sockets are a chapter in the book no the whole book. He meant to limit the scope of a socket library so that it might actual get finished. I refined that idea by comming up with my layers which we've been using for the last 3 or 4 years.
I agree that it is sad that a network library has been discussed for several years without any practical result. But this is an organizational problem. We shouldn't make it even worse and let the design of the network library be influenced by that.
In the requirement list Beman Dawes wrote I can see three layers (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/S...). I don't know where he wrote we need an extra layer for standard application protocols. Furthermore these layers are just an example. There is no explanation why a network library should look like this. In my opinion this is exactly one of the organizational problems we have: There is a lot of talk but decisions are not written down. They do not need only to be written down but must be explained. If it had been done before we wouldn't need to start over and wouldn't need to question everything what was written down once without any explanations in the Wiki.
From the requirements.
*Reasonable size *In the overall scheme of C++ libraries, sockets are part of a chapter, *not a whole book. Higher level protocols, such as FTP and HTTP don't *have to go in the same chapter. Don't get carried away. Standard protocols are built using either layer 2 or Layer 3 components so the naturally form another layer. They also should not be part of the networking library. I would also add that this represents the OSI Applications Layer.
That's why I put up http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. This is not "yet another network library" but a list of problems and requirements which will hopefully lead us to a design of the network library. The package diagram at http://www.highscore.de/boost/net/packages.png is my continuous attempt to put everything together.
Thats why I'm objecting to you subtracting 1 from the layer numbers.
I don't remember who participated in the discussions several years ago. Since the discussions were revived on 3 March we (not only me) have been talking about level 0 and level 1 and everyone seems to have understood. I don't mind to change the name but then everyone has to do of course. But do we really have to change names which are used now for 2 months? And do we really have to discuss if we should rename level 0 to layer 1 because some people called it layer 1 several years ago? Let's concentrate on more important things please.
You will obviously do as you please but I was simply trying to remove one of the elements of confusion that I see regularly see between you and Don by reverting to the Layers in Beman's requirements document and that have been used consistenly for some time until very recently. /ikh _______________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. _______________________________________________________________________