"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote:
"Eugene Alterman" <eugalt@verizon.net> wrote
There is nothing special about synchronous operations, and they have been implemented in similar ways in dozens of networking libraries.
See, I don't care much about other libraries -- I am not going to use
"Ben Artin" <macdev@artins.org> wrote them.
But if this one becomes part of Boost, I may start using it, and so I would like it to have what I need, with a clean interface, and implemented in a clean way.
IMO this is completely beside the point. This is not the boost networking library, it's the boost async IO library, and as such whether it supports sync IO or not is completely irrelevant.
When I was reading through the library tutorial half of examples there were related to the synchronous IO. And, in all these examples a demuxer object was used, that has nothing to do with synchronous IO. Do you think this is a clean interface? Do you think having to create and pass around an object, that is conceptially not required, is irrelevant? If the library doesn't want to support synchronous IO this is fine, but since it does support it, how it is supported becomes relevant.
There are really two possibilities here:
1) You may some day use an async IO library, in which case this library will be useful to you and you should review it for its merit with regards to its stated design intent or 2) You will never use an async IO library, in which case this library will never be useful to you, and you should still review it for its merit with regards to its stated design intent, while acknowledging that it does not necessarily fit your problem domain.
However, right now you seem to saying that you are not interested in async IO, and that this library, whose stated intent is to provide async IO, is
I was under impression that I am reviewing it right now :-) There is a third possibility, which IMO is more probable, that I will want to use some combination os sync and async features. That's why I would like to see them nicely fit together. therefore
unacceptable to you.
This is a total mis-interpretation of what I have been saying.
You have a nail. This library is not a hammer.
IMO, if you want a clean synchronous IO API, you should not be looking for it in an async IO library.
If the lirary has the support for synchronous IO API, it should be clean. Either have a clean support or no support at all. Regards, Arkadiy