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