Re: [boost] [asio] Library Review

From: Ronald Garcia (garcia_at_[hidden])
Date: 2005-12-29 04:19:14

To be clear, I vote YES to accept asio into Boost.

On Dec 27, 2005, at 10:30 PM, Christopher Kohlhoff wrote:

>
>> Based on the daytime tutorial, I am concerned that not enough
>> high-level functionality has been added to the library.  The
>> daytime examples still have the flavor of using unix sockets.
>> I think that this low-level functionality is critical to
>> flexibility (and perhaps performance), but I would like to be
>> able to quickly construct simple network applications as well.
>
> I'd like to see something like this layered on top of asio as a
> separate framework. There are many different styles and
> approaches to take, so it may actually be multiple frameworks :)
>

I think that the above reply relates to many of my concerns regarding 
the library.  A strong emphasis has been placed upon efficiency and 
functionality for this library.  Perhaps some of the functionality that 
I mentioned (support for iterators and strings) could be added to asio 
or deferred to a higher level interface.  I am not sure where the line 
should be drawn with respect to these pieces of functionality.  
Furthermore, they only seem additive upon the design expressed in asio 
as is.  It is with that in mind that I vote YES to accept asio into 
Boost.  I do hope, however, that higher-level interfaces to the 
functionality in asio are forthcoming (and I hope to have some time 
soon to look for the iostreams example).

>
> <snip>
>> 2) How can one interleave asio's demultiplexing facilities
>> with other existing event-based libraries.  I'm afraid I have
>> not had time to investigate whether and how this can be done
>> in asio currently. But some applications will require mixing
>> asio into some other master event loop. Something of like
>> demuxer::run_one_event() would be a good start.
>
> Based on other feedback, I already plan to add demuxer::run()
> overloads that take a timeout indicating the maximum time that
> they are allowed to execute.
>

This sounds promising.  The interface I had in mind above would block 
until one asynchronous event were handled (or return immediately if 
none are pending).  I am not sure if this is a worthwhile to have in 
addition to the hard timer.

> <snip>
>> Code Comments:
>>
>> It was necessary for me to make the following changes to the
>> library in order to prevent warnings and to compile under OS X
>> (Panther/10.3):
> <snip>
>
> Unfortunately there are other issues with support for 10.3, such
> as the lack of thread-safe DNS functions.
>

Can 10.3 still support much of asio, or is the above a killer?

Cheers,
ron