I vote to accept asio into Boost. I don't have a lot of experience with networking, so I give myself only 1/5 of a vote. In addition, I have not been able to use asio in production-quality, network intensive code. I have used it at home in a networked application that depends heavily on timeouts and noticed no problems (although I did seem to get exceptions from Boost::DateTime after a couple days). It was easy to use. I will continue to look at it a bit more, but based on a) the lack of problems so far and b) my inexperience with this topic I will find anything meriting a no vote. As usual, more documentation would help, in particular overview of internal architecture, possibly an expansion of the "Design" page. Existing documentation ain't bad. Example code is very easy to follow. In general, what Dave Moore wrote fits my intuition about asio: Dave Moore wrote:

I vote to accept asio into Boost. I have previously experimented with earlier releases in the asio 1.3.x series. Using asio, I have built proof-of-concept applications that compile on Linux and Win32 handling udp multicast traffic at peak rates in excess of 100Mbit/s with low CPU utilization and no packet loss, even when compared with an existing hand-coded production implementation.

[That's very reassuring.]

Asio represents a serious effort at cross-platform networking by someone who clearly understands the problem domain. I have been representing it to my colleagues as "ACE without the cruft."

[That's my sense too. In particular I did not have to wrap anything with ACE stuff.... What exactly is "cruft" and Dave do you mind elaborating on this point?] [snipped rest]

David Moore _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Dave, --- Dave Moore <jdmoore99@gmail.com> wrote: <snip>

For the deadline_time, I am unsure as to whether functions like "expires_from_now" benefit from their default coupling to boost::datetime. Most timer operations in high performance I/O tend to be relative, which is easily expressed without a clock binding. It does help that asio only depends upon the headers of datetime.

What did you have in mind? I rather like the date_time way of expressing units as an aid to code documentation: timer.expires_from_now(seconds(5)); <snip>

The Doxygen docs are a bit hard to navigate. I would prefer hand-written documentation of the common public classes and concepts like buffer, deadline_timer, datagram_socket, etc. Doxygen docs are useful for completeness, but is seems to me like many of the classes in Boost::asio are of interest only to those looking to extend the framework. The documentation could be split into sections for users looking for basic async sockets, and users wanting to write their own services or demuxers.

Fair points. I would like to spend some time writing book-style introductory documentation that addresses this sort of audience by ignoring the basic_* templates and treating them as though they are classes (same as basic_string vs string).

There weren't obvious instructions on how to overlay the asio boost evaluation package into an existing boost source tree. It seems like the installation/compilation docs apply to the standalone asio distribution, not the Boost evaluation package.

I'm surprised I left that doco in there, but yes a bit more explanation could have been useful :) Cheers, Chris