DOM EventStreams (take two on Streams): Request for feedback

Tab Atkins Jr. jackalmage at
Thu Apr 18 17:48:14 PDT 2013

On Thu, Apr 18, 2013 at 4:26 PM, Jason Orendorff
<jason.orendorff at> wrote:
> (narrowing to the part that seems most productive)
> On Wed, Apr 17, 2013 at 9:11 PM, Tab Atkins Jr. wrote:
>> On Wed, Apr 17, 2013 at 5:50 PM, Jason Orendorff wrote:
>>> Bacon offers two equivalent ways of unsubscribing.
>>> 1. Bacon's equivalent of the StreamInit callback returns an
>>> unsubscribe function. Each subscriber therefore gets its very own
>>> unsubscribe callback.
>> Ah, that's an interesting idea.
>> I'm unsure how each subscriber gets its own unsubscribe callback.  The
>> init callback is only called once, and so returns only the single
>> value, right?
>> Or is the subscribe callback called every time someone starts
>> listening, so the stream can potentially act different to different
>> listeners?  That seems like it would be hard to make compatible with a
>> multi-listener approach.
> Right. It's not quite per-listener; as in your design, the EventStream
> class copes with multiple simultaneous listeners.
> But when the number of listeners on an EventStream goes from 0 to 1,
> it calls the subscribe hook; when it goes from 1 to 0, it calls the
> unsubscribe hook.
> This is because Bacon turns off all the taps when no one's listening.
> Futures are not like that.

Hm, I'm not sure I'm grasping exactly what this does or how it does
it.  I'm not sure what Bacon's Dispatcher concept maps to, or how its
API actually works.

> This is indeed usually caused by the last listener unsubscribing by
> returning Bacon.noMore; and this is the point where I think it'll be
> quickest to cut short the discussion and just read some Bacon source
> code.
> This is called for every event:

I don't understand how the subscribers reply to the dispatcher with a
value.  I think there's a decent mismatch in API shapes, which is
making it hard for me to follow.


More information about the es-discuss mailing list