[boost] Re: [network] An RFC - updated

From: Boris (boris_at_[hidden])
Date: 2005-04-25 08:36:58

Don G wrote:

Hi Don,

> [...]
> Where we diverge perhaps is level 1. I think the first thing that
> should be done with sockets is to hide them behind a complete
> abstraction. The only reason for writing code to level 0 (outside of

actually I agree again. I think from now one I just assume that you talk 
about level 1 all the time. :)

> [...]
> So, in my view of the world<g>, I see something like my proposal as
> level 1. There should not need to be anything else at level 1. It is
> a complete abstraction (or should be made so).

I agree again. In my view of the world level 0 is as much low-level and 
level 1 as much high-level as they can be. If anyone wants to introduce 
another level of abstraction he needs good reasons to do so and make a sharp 
distinction between such a new level and the other two. Right now I think we 
have no reasons to assume that we need a third layer.

> [...]
> I am having a hard time with the limits of English (C++ is more
> expressive<g>). At level 0, sockets provide send and recv as they
> always have, just wrapped for safety, convenience, portable error
> code returns, etc.. Which is why I cannot see how ssl_stream could
> derive from the socket wrapper class. Even if these were virtual, if
> the socket base class provides a get_fd() method (which I think it
> must), a derived ssl_stream would violate the rule of substitution
> unless you play some expensive games.

Maybe I should have written ssl_socket and not ssl_stream. What I was trying 
to say is that level 0 should be as complete as Berkeley sockets are. If 
someone wants to create a ssl_socket class it should be possible to do with 
level 0 classes. I understand that there is interest in improving the API 
and get to a higher abstraction - I completely agree that we need a layer 1. 
However I am also very much interested in a complete layer 0 and think we 
need this layer (reasons below).

> [...]
> I understand your point now. I was trying to satisfy the desire of
> some to chose an implementation for platforms that could have
> multiple choices (select + poll + kqueue). I don't think this is
> something most users would ever do, but there is room for the app
> developer to chose what class they instantiate for the network. I

I will update http://www.highscore.de/boost/net/packages.png and add a 
package "platform-specific" just for completeness.

> [...]
> Not at all. I just don't see encouraging anyone to work at level 0.
> All higher level thinking is above that. In particular, the
> abstraction I am proposing is level 1 (my definition again<g>). But,
> that level 1 abstraction is ideally very much like level 0 in terms
> of network semantics, just not so much like the sockets API.

I agree with what you said about level 1.

> [...]
> I would say that level 0 is a direct, perhaps even inlined wrapper
> over sockets (see above). For legacy code, that would be useful. Even
> for experienced developers, I believe they would be much better off
> (give or take some radical optimization requirements) with the layer
> I propose. If they see it otherwise, level 0 is there and is a
> supported library for use by anyone.

I think we need a complete level 0 which is as low as possible for one very 
important reason. It isn't so much about legacy code or that we couldn't 
implement level 1 without level 0. It is because the majority of network 
developers knows Berkeley sockets and the C API and has a lot of experience 
with these concepts. If we follow the ongoing discussions here in this list 
it seems like everyone created a network library himself. What are the 
reasons for this? Either developers had very specific requirements and were 
forced to create their own network libraries - however I can't believe this 
with so many network libraries out there. Or developers didn't want to spend 
time to learn about the design of other network libraries and understand 
their advantages and disadvantages and decided to create their own network 
libraries based on Berkeley sockets.

There have been many complaints recently in the thread "Boost to the rescue" 
that C++ is losing ground. If we want network developers to switch over to 
the C++ network library we should help them to reuse their knowledge and not 
force them to forget everything they know and get used to new concepts. I 
think I view level 0 is a very low entry barrier for today's network 
developers - without such a very low entry barrier I fear we have a hard 
time to convince network developers to switch. Eg. when I try to understand 
the design of a network library I search for the socket class first. It 
helps me to see something familiar and I start exploring the network library 
from the socket class. Being confronted with unfamiliar concepts in level 1 
network developers might decide to develop their own network libraries 
*again* instead of using the brand new Boost C++ network library.

In the long term it would be nice if everyone was using level 1. But even if 
we manage to create a level 1 which meets all requirements network 
developers ever have I don't think we can convince network developers that 
our network library really has such a great level 1. These strange network 
developers want to build something up themselves based on Berkeley sockets 
all the time. :)

Boris