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