Decouple the facade from the client

[arnonmoscona]

Currently the facade knows about the client. Most applications are not all that high performance as the original and I can afford to make things cleaner at some performance cost.

• use mbassador to publish events. Make sync or async a constructor function.
• client just subscribes to messages
• facade can be a supplier as well, probably by creating a simple subscriber that exposes a supplier which blocks until the next message
• the supplier can then become a stream simply by Stream.generate

[arnonmoscona]

Step 1: break the facade into two pieces:

• The core would be completely decoupled from the client and the client interface by substituting all calls to the interface by event publishing
• The second piece, which may be integrated into the client or kept as a separate class, will use handlers to intercept the events. It could be that all it would be is making all the interface methods in the client into handlers
• One challenge may be data types, as most of these handlers accept a string, so pure class based subscription will not work
• The real confirmation that this work would be the ability to hook multiple clients to the same facade, which is not allowed in the old code (1:1 relationship there)

[arnonmoscona]

Mbassador does not have a direct way to distinguish between "multiple topics" with the same message type (String in this case). Creating a wrapper type for each message would just cause a lot of temporary object noise.

Most likely, I will need to use a separate Mbassador instance for each iqfeed socket. this way their string message subscriptions would be naturally separated. The only thing is that I will need to encapsulate the subscription process such that the client implementation would need to expose separate objects to invoke the right handlers. The client may need to maintain a separate class for each iqfeed channel, or something like that.

[arnonmoscona]

Issue moved to http://moscona.myjetbrains.com/youtrack/issue/IQ-5