I vote to *not* accept Asio as a Boost library. This is based on some specific deficiencies in design/implementation and documentation. Hence if those are remedied I would be willing to change my vote. What is your evaluation of the design? Fair -- The overall separation of responsibilities is good and provides for considerable reuse. And possibly independent use of many of the facilities. Unfortunately many of the interactions and dependencies between the parts are not clear. In many situation I had to resort to reading through the implementation to figure out the various connections. Even though I can see how I would use the library in some tasks there are others I just don't see how something could be implement in an efficient manner. (More below on my specific use case) What is your evaluation of the implementation? Good -- For the given design the implementation is clear and easy to follow. But because of some particular design choice(s) there are some serious performance deficiencies which I would think prevent its use in the one area where the library was ostensibly design to be used, high performance servers. What is your evaluation of the documentation? Insufficient -- Even though I'm a proponent of Dox style automated documentation in this case the Dox reference documentation is insufficient in describing how the various operations work. The supporting design, tutorials, and examples I don't feel provide sufficient background to understand how the pieces connect and react with each other. Specifically the example code should at minimum explain why calls are done. In summary, either the reference docs need to improve significantly, or the non-reference docs need to take up the slack. What is your evaluation of the potential usefulness of the library? Good -- Even with my concerns about efficiency I can see the use in the wider connection based client/server domain where response efficiency is a minor concern. Did you try to use the library? No. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth -- I read a good portion of the documentation, and various parts of the implementation with a particular use case in mind. Are you knowledgeable about the problem domain? Yes. I have done some form of networking programming for the past 10 years. In the form of HTTP handlers, Game multiplayer games, and most recently client/server version control system. Now some details about my use case and my performance concern... I am looking at Asio to provide the socket handling for one of my current projects, the version control system. I'm in the middle of rewriting the networking aspect of it from the classic thread per client model to an async endpoints and routers star to star virtual LAN topology with a custom reliable message protocol based on UDP. This means that since I'm writing my own router I need the best performance I can get. But to give some minimal concrete numbers... Given a single gigabit line, a minimal example as a server is likely going to have multiple lines, and the most favorable situation of handling full 64K UDP packets one would need to handle about 1500 messages a second (or 2/3 of a millisecond per message). But in practice it would have to be faster than that. This means minimizing the most expensive steps, i.e. memory allocations. Currently AFAICT in order to use the async operations asio requires a model which allocates a new handler for each message received. This might be fine for many situations where those handlers will change from message to message. But for my use case I have only one handler that needs to get called for *any* message that comes in. In the asio case it means that for each message I received it would: remove the handler from the demuxer map, call the handler, which would do my custom parsing and routing, and push a new async_receive of myself (which creates a new handler object and inserts it again into the demux map). This is clearly suboptimal, and will result in considerable performance degradation. To refer to some concrete code, one can look at the Daytime.6 tutorial which does basically that procedure. Of course it would be awesome if Christopher would come out and tell me I'm stoned and point out how to achieve the optimum I need. Barring that for me to use Asio for my project I would end up creating patched versions of epoll_reactor, kqueue_reactor, reactor_op_queue, reactive_sokect_service, and win_iocp_socket_service (maybe more). Such hacking of implementation classes to me means a serious design failure. Here's to hoping I'm wrong ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org