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