Re: [boost] Re: [sockets] layers concept
On Tue, 2005-04-26 at 13:54 +0300, Boris wrote:
Iain K. Hanson wrote:
Hi
I created the layers concept for the C++ Networking boost library.
The layers I defined are:
Layer 1 :- Light weight wrappers arround predominantl BSD socket concepts.
Layer 2 :- Acceptor, Connector, Reactor, and Svc_Handler concepts ala ACE.
Layer 3 :- An optional iostreams interface if desirable?
Layer 4:- Applications layer - includes ftp, telent, http/s And user applications
Is layer a package or a level of abstraction? I ask as I wonder if eg. layer 3 is based on layer 2?
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.
If you look at http://www.highscore.de/boost/net/packages.png I put the packages "ace" (your layer 2) and "iostream" (your layer 3) both in layer 1 because they don't necessarily depend on each other and I don't know if we can tell which one of the two packages has a higher level of abstraction.
[...] Boris has also been atempting bto model Layer 1 but keeps calling itlayer 0.
Hey, everyone called it level 0! :-)
we need a common nomenclture or confusion will reign.
That's why I added the link to the package structure at http://www.highscore.de/boost/net/packages.png everywhere to make sure we talk about the same. It's quite similar to your layers concept except that you created new application layer.
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. Thats why I'm objecting to you subtracting 1 from the layer numbers. /ikh
Iain Hanson wrote:
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm not sure why, but all of your replies appear as email attachments rather than direct replies. Are others seeing the same? Can you provide direct replies? Or is this something peculiar on my end using Outlook Express newsreader with the gmane newsgroups? Thanks, Jeff Flinn
On Tue, 2005-04-26 at 08:54 -0400, Jeff Flinn wrote:
Iain Hanson wrote:
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm not sure why, but all of your replies appear as email attachments rather than direct replies. Are others seeing the same? Can you provide direct replies? Or is this something peculiar on my end using Outlook Express newsreader with the gmane newsgroups?
I think it may be an interaction of Outlook and PGP. I've turned the PGP off for this email. let me know if it makes a difference. I use Evolution and my messages come back to me fine and they show up in the archive as text. /ikh _______________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. _______________________________________________________________________
Iain K. Hanson wrote:
On Tue, 2005-04-26 at 08:54 -0400, Jeff Flinn wrote:
I'm not sure why, but all of your replies appear as email attachments rather than direct replies. Are others seeing the same? Can you provide direct replies? Or is this something peculiar on my end using Outlook Express newsreader with the gmane newsgroups?
I think it may be an interaction of Outlook and PGP. I've turned the PGP off for this email. let me know if it makes a difference.
Yep, that did it. Whatever PGP is. :)
I use Evolution and my messages come back to me fine and they show up in the archive as text.
Thanks, Jeff
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. 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.
[...] 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. 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. Boris
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. _______________________________________________________________________
Iain K. Hanson wrote:
[...] 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.
I think the confusion between Don and me was not about layer names but to find a position for his library in the two layers we have so far. We were trying to figure out what goals each layer should have and in which layer Don's library fits better. In the end I am more concerned about a clear distinction between layers and packages than about names. If the design is clear and easy to understand I will accept any name - even Boost.MickeyMouse. ;-) Boris
participants (4)
-
Boris -
Iain Hanson -
Iain K. Hanson
-
Jeff Flinn