Chris, Sorry for the late response. A delivery and the flu got in the way. --- evaluation of the design --- The design documentation is well written. How should a boost user deal with porting synchronous I/O code between platforms? Should asio be expanded or will a separate library mix well with asio? This has already received a lot of attention. --- evaluation of the implementation --- Looks good. I did not make a thorough investigation. --- evaluation of the documentation --- = tutorial = The tutorial was a good introduction to the library. = examples = It is not straightforward how the Service example eventually calls the log method. Maybe an explanation of this would help the reader bring it all together in their mind. = references = The "Size_IO_Control_Command concept" needs a better description. There are other concepts that have nondescriptive descriptions: IPv4_Address_Socket_Option, Integer_Socket_Option, Boolean_Socket_Option, ... For example, is the user of asio supposed to just know the requirements of the "Stream concept." or should some of the requirements that define the stream concept be stated in its description? Or is the list of types and member functions the requirements of the concept? I do not like to be picking on the documentation like this because it is very well written. I think that the design and tutorial are great at introducing a user to the library. I just think that a few sentences of description (requirements) of a concept will help the reader understand each concept more quickly. --- evaluation of the potential usefulness of the library --- I think that Boost needs a library that addresses the goals stated in asios rationale. The lack of synchronous I/O support makes the library less useful than it might be. --- Did you try to use the library? --- answer: no --- How much effort did you put into your evaluation? Answer: I read all of the documentation. --- Are you knowledgeable about the problem domain? Answer: I have about 10 years of active use of C++ using TCP and UDP on multiple platforms (including Linux, Solaris and Windows). Most of it has been using ACE and its Reactor but I have also implemented using the Proactor (asynch I/O). --- Do you think the library should be accepted as a Boost library? I think that asio should be expanded to support a synchronous/reactive I/O as well as its current asynchronous support. If the intent is to do so then I believe the library should be accepted. Since performance is often a consideration in networking code, I do not think that synchronous support should be built on top of asynchronous capabilities. My experience with asynchronous I/O vs synchronous I/O (ACE_Proactor vs ACE_Reactor on Windows 2000 across 8 machines on a gigabit network in an application of 1000+ simulation objects) was that I needed to have > 200 pending I/Os for the Proactor to out perform the Reactor. This implies that the problem space must include large number of non-dependent asynchronous reads and writes for asynchronous I/O to outperform a reactive approach. My experience is that most applications do not have that many parallel I/O operations. Regards, Scott