Re: [boost] Re: Re: [sockets] layers concept

From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2005-04-27 13:33:12

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/SocketRequirements). 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.
_______________________________________________________________________