"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
[snip]
I would expect both asio and a stream API to be layered on top of low-level socket API. This socket API should wrap the platform dependency, but otherwise provide pretty much the same capabilities as current C socket APIs provide, with minimum overhead.
The key problem with that approach is that a `thin' wrapper over the platform APIs is basically useless for implementing asynchronous operations, because asynchronous operations must be implemented in widely different ways on the different platforms.
For synchronous operations, it happens to be the case that every platform provides basically the same interface, so at least a portable (but not necessarily very good) interface can be created through only a thin wrapper.
Then maybe it would make sence to define this kind of API for synchronous operations, while asio encapsulates asynchronous IO using a higher-level abstraction. The socket class would be cleanned from the asynchronous stuff, and used by both asio and synchronous API. My problem with the current approach is that synchronous operations seems to be viewed as second-class citizens. I understand that this is caused by the fact that asio is about the asynchronous IO. But asio is presented as the "best C++ networking library around", and in networking both synchronous and asynchronous approaches are used, and neither is superior for all possible cases. Consider "Patterns for concurrent and networked objecs" by D. Schmidt, at al. Quite a few patterns described there are related to the synchronous processing. I think a little refactoring might lead to a better solution than trying to add synchronous operations on top of existing asio. Regards, Arkadiy