"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:dnq894$11t$1@sea.gmane.org...
All I was trying to say is that, as a potential client of the library (everybody does some networking now and then), I tried to map it to one of the tasks I had in the past. I happen to have solved that task by using synchronous operations + multiple threads (maybe because it is the most intuitive way for a not very experienced network programmer, which I am, but I still doubt very much that asynchronous approach would have been better).
If you are using socket API or a C++ library that just provides simple wrapper classes for socket API a thread per conection approach is of course the most intuitive. The problem is that it does not scale well.
So, when I am evaluating a "Networking Library", and see that it clearly consideres one approach to networking inferior to the other one, and I think they both are equaly important, that means that I am in fundamental disagreement with the library author on the subject, and makes me wonder whether this is the networking library I would like to see in Boost.
One approach is inferior to the other and they are both important (but not equally) :-)
Besides nobody yet convinced me that socket should depend on demultiplexer.
It does not. The real reason it depends on demuxer is that it contains the socket service. Otherwise demultiplexer could have been passed as an argument only when performing asynchronous operations.
The fact that it "has been proven to work well" is "not enough of an excuse", IMO. Otherwise this review would not make any sense.
I totally appreciate the fact that the library has a lot of positive reviews, and, as you say, proven to work well. All I want is that the synchronous approach to networking was given enough attention, and added cleanly rather than as a fast fix -- a wrapper around asynchronous stuff.
It is not.