On 01/27/2014 11:16 PM, Gavin Lambert wrote:
You flip it around. Instead of having an event listener object that is registered on some event provider source, where the provider source invokes the methods explicitly when an event arrives, you have anything that is interested in events invoke an async request on the source object. So it'd be something more like this:
class gui_source { public: // actually using templates to make the callback more generic void async_key(void (*callback)(error_code ec, int key)); void async_help(void (*callback)(error_code ec, int x, int y)); };
The code on the receiving side just handles a callback instead of receiving an explicit call, but otherwise it's basically the same.
This is an intesting idea. Although it does involve a lot of plumbing, I agree that it can be done. As we are exploring the limitations of the Asio model, let me introduce a use case that is difficult to do within this kind of parallel initiator-callback paradigm. Consider a secure RPC server, whose full API only can be used if the client has the correct privileges. For simplicity, let us assume that this is a single-client server. There are two modes: unauthenticated and authenticated. In unauthenticated mode, the server should reject all but the authentication requests. The way you typically would do this is to have separate implementations of the API for each mode, and when the client has been authenticated, the server will switch from the unauthenticated to the authenticated implementation. This wholesale replacement of the underlying implementation is much more difficult to do with the parallel initiator-callback style. We could solve the problem with another level of indirection, but that would effectively re-introduce the event listener.