Antti Vähäkotamäki

I think this mode could be very beneficial also for scenarios other than streaming, but the naming does not really promote it's use. If I understand this correctly, the feature...

I did some more test and it seems like looping through all of the registered functions and calling `client.unregisterWorker( fn )` for each of them actually gets me the result...

I did a quick test by modifying the `forgetAllWorkers()` and got it working properly by changing the current implementation: ``` Worker.forgetAllWorkers = function () { if (! this._workersCount) return; this._workers...

If disconnect can work that way, it sounds really good. I haven't worked a lot with streams yet -- do they have an easily inspectable internal state, which can be...

Actually.. What I am aiming to achieve with this is that the worker would execute it's job only once.. So is there a way to "disable" the worker somehow or...

I think maxTotalJobs sounds good as a feature. Attaching disconnect on 'unregister' however feels a bit awkward as I would expect the unregister event to be fired instantly when the...

I think this is a good idea. However it got me thinking: If I want to spin up a worker to do exactly one work (and exit afterwards), what would...

Have I understood correctly that the "non-streaming" mode is pretty much the default in many other libraries? A very non-magical way to do this would be to have a different...

Yes, it would be a "no op" (immediately fulfilling promise) and I would consider that valuable just to keep the interfaces consistent for streaming and non-streaming workers. If you used...

What if we try to split this into smaller questions? The first one for me is that I find that the streaming workers and the non-streaming workers seem to have...