Fellow Boosters, this is an update on my proposal for a Boost.Network library, located in the Sandbox. The file is called network.tar.bz2 or network.zip, located in the pedro_lamarao folder. The library was downloaded by a few people; I'd like to talk to you if you actually tried to use it. The layout of the archive is the familiar boost directory layout, ready to be expanded on top of a boost release. It was worked on a CVS HEAD version of boost. Every new name was added into a boost::network namespace. Every file is licensed under the Boost License; I've already secured the copyright over the code with my employer, pending the formality in paper. BoostBook documentation is provided with a Jamfile.v2 for bjam, but with many sections still empty. There is currently a Tutorial and an Overview of the library; the References section is still just a skeleton. The documentation can be found here: http://mndfck.org/~pedro.lamarao/projects/boost_network/ The header layout is now more closely what I think should be in a formal proposal for standard networking IOStreams. Comments on this would be much appreciated. Examples are provided in subdirectories of the libs/example/ directory, each with a Jamfile for bjam. These examples are still far from what I think is possible to achieve, but already show some interesting coding patterns facilitated by the IOStream interfaces. The examples include: - Spirit based internet::abnf class, containing the standard ABNF rules; - Spirit based internet::uri class; - std::getline based http_response class; - Spirit based irc::message class; - threaded servers for the chargen, daytime, discard, echo, qotd and time protocols. Yes, I forgot to add license notes in every example file. I'll correct that in the next days. I'll complete the examples with an smtp_client application, based on an internet::message and an internet::smtp_transaction, and a length-prefixed "binary" protocol. The implementation of the IOStreams does no buffering or code conversion: this is the simplest case, and offers the worst performance possible by making a system call for each byte read from the network. On a fast machine with a 256 kbps link the overhead is difficult to notice; slower machines and/or faster links make it more evident. Adding buffering is easy, though, as I've done it before; I could throw a quick patch for someone interested in benchmarking it. Code conversion is trickier. -- Pedro Lamarão