stratus51 / typescript_emitter Goto Github PK

The relay method name does not seem very clear.
In addition to that, there is a lack of the dual function: plug output of the current emitter to another emitter.

If a listener throws an error, it prevents any further propagation of the signal to the next listeners.

Should we force the Emitter test to verify that signals aren't lost upon error emission?
What should we do with the potential caught errors? (Global error callback? Per listener error callback?).

A new type of emitter would be useful: a load balancer.
It would have the same prototype as the first emitter except that subscribed callback would tell whether the have successfully processed the package.

The newly required acks could be processed synchronously or asynchronously (payload processing could require I/Os).
There should probably be 2 separate implementations because the asynchronous implementation will probably consume quite a lot of memory compared to the synchronous one.
The synchronous one will also easier to implement.

The acks should be integrated in the map, filter and relay methods.

The sub_until methods should probably be helpers instead. I guess it would be cleaner.

This would allow checking whether the result will be used and avoid resource heavy operations if no one is listening.

This would might allow to get rid of the "new_emitter" method and get a non abstract type as return type for all the common methods (map, filter, ...).

Is pub/sub naming relevant?

As the enhancement issues are suggesting, the lib might be migrating to a object stream model. Therefore would a push/each naming convention (iterators) be more relevant?

The Emitter manages both an input stream and an output stream. As such, it as common to try to map the input as it is to map the output.

Currently the output can be mapped using the map method. However, mapping the input requires quite some boilerplate.

Should this new method be named "map_input", or "wrap", ... ?

If we could split the Emitter into some kind of EmitterSender and EventListener, each keeping their associated methods (map, filter, map_input, ...), it would allow the code to restrict the actions possible on the forwarded emitter.

For exemple, only a Sender would be forwarded to a producer and a Listener would be sent to consumers. This would insure the consumers don't accidently inject packets to other consumers for exemple. Also the code would be clearer about whether the Emitter handle is used as a source or as a sink.

In practice, an I/O client will often serve as a builder for multiple data streams (request streams over different topics on MQTT or AMQP which will have to be processed independently).

Formalizing the notion of an emitter builder could be useful?