Caleb Epstein wrote: Hi Caleb,
[...]
This is more about the big picture, stacking more complex interfaces on top of it. I think we should implement iostreams for sockets first, then we can go on to implement the mighty httpwistream that will give you "wchar_t"s, whatever the document encoding was. :-)
I think we should implement C++ sockets first, and then iostreams on top of those.
I know there have been others that have agreed with this approach before. Are any of them following this thread?
basically I agree with you - we have been through all these discussions before. However as there is so much to do for a socket library I appreciate it if from time to time something is proposed at all (like this socketstream library now :-). There are still all the requirements in the Wiki which I tried to put in the UML diagram at http://www.highscore.de/boost/net/packages.png (which also includes socket streams of course). Personally I am also more interested in the low level interfaces. We still have to come up with a proposal how the asynchronicity pattern should look like. Then we could start building up classes for the "Berkeley" package. Unfortunately I had not much time lately but hope to go on working on the asynchronicity pattern next. As socket streams won't support asynchronous I/O (I think these were the latest news?) someone could go on building socket streams (the implementation could be based on the "Berkeley" package later). In the moment the low level "Berkeley" package is waiting for the asynchronicity pattern. Boris