Optimization: set subscriber thread up before connecting

[sharpe5]

Currently, the codebase passes all of its tests and works reliably for me.

However, if we wanted to eliminate the 500ms delay on subscription instantion, we could potentially do this by ensuring that the subscriber thread is up and running before connecting.

[somdoron]

You can also consider not using the pub sub pattern. Router dealer with
kind of login handshake. Also every new subscriber gets all history
messages?
On Feb 13, 2016 13:23, "sharpe5" [email protected] wrote:

Currently, the codebase passes all of its tests and works reliably for me.

However, if we wanted to eliminate the 500ms delay on subscription
instantion, we could potentially do this by ensuring that the subscriber
thread is up and running before connecting.

—
Reply to this email directly or view it on GitHub
#23.

[sharpe5]

I absolutely agree. This is the direction the design is heading in, see issues #7 and #12.

There are two broad aims for this library:
1). A simple API.
2). It just works.

Currently, 1) is looking good, but 2) is not quite there. The main problems are:
a) The subscriber might miss messages if it connects after the publisher has published some items;
b) We have to have a separate port and TCP/IP connection for every new ISubject of T.

Once we address these, the library will be a lot closer to "just working". There are a few other enhancements such as MsgPack support and a dynamic/floating daemon, but these can be handled later.

I've had a lot of experiencing writing C# wrappers over Tibco, and the aim is to eliminate all of the sloth dung that Tibco tends to shovel at its developers.