Support volatile subscriptions

[koivunej]

Making this issue to document what I've learned on subscriptions share my current thoughts on how to possibly proceed.

As I mentioned in another thread, the sequence of messages seems to be:

C: request_id: 1, payload: "subscribe to Foo"
S: request_id: 1, payload: "subscription started"
...
S: request_id: 1, payload: "notification on Foo"
... until either
C: request_id: 1, payload: "stop subscription"
S: request_id: 1, payload: "stopped because you unsubscribed"
...or...
S: request_id: 1, payload: "stopped because $reason"

Using tokio_proto::streaming::multiplex would almost allow supporting the whole conversation with notifications and "stopped because $reason" being the body chunks. However client sending "stop subscription" would have to somehow bypass the multiplex layer altogether, which I do not think is possible.

Other way would be to write a custom, more general multiplex support that would effectively create separate (Sink, Stream) pair for each request_id. As noted in the linked tokio_proto issue discussion, there might be more usage for such implementation than just the ES protocol.

Other thing the custom "more general multiplex support" could support is server sending something which is not in response to anything client requested. With ES these would be the heartbeat messages sent by server.

[koivunej]

This was never solved.