Hi Doug,
Here's more motivation: the C++ committee is planning to finish the next revision of the C++ standard in the next few years, and I stress *few*. Boost has been a wonderful source of libraries for the C++ committee, and C++ would be greatly improved if the next version of the standard library contained a sockets library... this library could be that library, but we have to finish it, review it, and be sure it's right. We can't review what doesn't come up for review. "Finished" is more important than "complete".
That possibility was actually my motivation for getting involved with Boost. :) I believe that the proposal I posted fits with this goal, while a "socket library" does not. It was only recently posted here, but it has been under development at my work (where I recently got permission to get involved with Boost) for many years. In the process of posting to Boost, I have reworked it a bit to make it more "boost-like". There are only a few concepts in general use that are not covered in my proposal, but those can always be added. The abstractions I proposed can be implemented on virtually any modern OS and, because it makes minimal assumptions about stream and address semantics, can describe a non-TCP/IP network (within limits, of course<g>). I have done so using HTTP tunnels and reflecting servers (as I mentioned elsewhere). Sockets are an API to a network. A concept, and not a universal one as far as I know. What is needed, IMHO, is a C++ description of those concepts, not a "wrapper over sockets" (though that would come at a lower level since sockets are just about everywhere we want to be<g>). It would be like having iostreams be a "wrapper over Windows Kernel Objects" ;). Clearly, it uses such things on Windows, but that API has no impact on the C++ interface, nor should it. Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com