[boost] [network] Boost.Network proposal v0.2

From: Pedro Lamarão (pedro.lamarao_at_[hidden])
Date: 2005-07-04 10:16:22

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