Hello all, One request that came out of the asio review was that some sort of iostreams support, similar to the existing iostreams example included with asio, should become part of the library's public interface. I'd like to start some discussion on what form iostreams support should take in asio. Here are my ideas so far, which only really cover the highest level. The goals of iostreams support are to: - Support simple use cases. (Does this include servers?) - Abstract away complexities like io_service (aka demuxer), host resolution, etc. In asio's CVS post-review I have changed the socket types to be "strongly typed", e.g.: ip::tcp::socket ip::udp::socket ipv4::tcp::socket etc.. Following this pattern, for protocols that are stream based (like tcp) I plan to include typedefs for iostream objects, e.g.: ip::tcp::iostream For a client-side connection, this could be used as follows: ip::tcp::iostream s("somehost.com", "http"); This would automatically resolve the host and service names, and take care of managing IPv4 or IPv6 protocol independence for you (i.e. it will try all endpoints returned by resolving the host/service until it gets one that works). What lies between this high level interface and the current asio interface? Exactly how much of it is exposed as part of the public interface? I know Jeff Garland has some ideas about integration with streambufs, so I'll let him expand on them. Others please do feel free to jump in. The internals of iostreams is not an area I am familiar with. Cheers, Chris