Hi Arkadiy, --- Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
Can your faucets change at runtime?
No.
Why is the ability to perform asynchronous operations a property of socket?
I chose to make asynchronous operations part of asio's socket interfaces because, in my opinion, having them there offers the best ease of use and gives maximum flexibility to provide efficient implementations portably.
I can see some contradiction here, since you tutorial provides a number of syncronous examples. Using the demuxer object in such contexts seems to be a conceptual overhead, and somewhat misleading.
With this tutorial, I was trying to demonstrate the library's concepts in stages, where each subsequent tutorial introduces something new. I think it's important that, as you move through the tutorial, you can see how the synchronous is mapped to the asynchronous. So the early examples simply don't use all of the functionality that's on offer. They still have to initialise the objects correctly according to the library's interface though.
Also, your library provides some socket API, and therefore, if it is accepted, I don't expect any other socket class in Boost in the nearest future, which means I would expect your classes to nicely wrap all of sockets, not only acynchronos ones.
I've been thinking about these issues since your email. My feeling is that a use case doesn't have to become very complicated for the asynchronous operations to be beneficial. But where a developer's needs are simple enough, I suspect that's also when they are going to want to use an iostreams-based interface. Since iostreams basically enforce synchronous operation, this seems like a sensible place to hide the demuxer and asynchronicity away. Cheers, Chris