Introducing a client framework (shell & iopub clients)

[anutosh491]

Towards #32

[JohanMabille]

The more I think about it, the more I feel we should not split the control and the shell channels in the client. The pimpl is good for isolating zeromq, then what I see is:

• an xheartbeat_client class, that runs its own thread, sending a "ping" message to the heartbeat each 100ms for instance
• an xiopub_client class, that runs its own thread, polling the sub socket and pushing the received message into a queue. The reason for this is to avoid losing messages if a client waits too long and too many messages accumulate in the sub socket inernal queue
• the shell and control socket can can be wrapped in a "xdealer_channel" (or any better name): they will share a common implementation and it makes sense to have them in a dedicated class rather than in xclient_zmq_impl

All these classes should send / receive zmq::multipart_t instead of xmessage, so that you don't have to store xauthentifcation in the "low level" classes.

The xclient_zmq_impl should provide the following methods:

void send_shell(xmessage msg);
std::optional<xmessage> receive_on_shell(timeout = infinite);
void register_on_shell(listener l);

// Same for control

std::size_t iopub_queue_size() const; // Not sure about this one
std::optional<xmessage> poll_iopub();
register_iopub_listener(listener l);

// Blocking call; this function will call one of the previously registered listeners
// depending on the received message (or if the iopub queue contains
// pending messages).
void wait_for_message();

It is responsible for serializing the messages before passing them to the dedicated channel, and responsible for deserializing them before returning them to the caller.

The client should also contain a client_messenger that will send stop messages to the heartbeat and the iopub threads.

[JohanMabille]

I think you need an additional socket in xiopub_client to be connected to the xclient_messenger iopub_controller socket.