Boost logo

Boost :

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 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. :)


Boost list run by bdawes at, gregod at, cpdaniel at, john at