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.
*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
> That's why I put up
> 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.
This email has been scanned for all known viruses by the MessageLabs Email
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk