Suggestion: Use the term “channel” for publishers and subscribers

[tomek-he-him]

Hi @kriskowal,

every entity you define has a single term for the thing and two terms for its input and output sockets. A deferred has a promise and resolver, a stream has a reader and writer, and so on.

I’ve noticed two exceptions to this:

1. A task has no terms for its i/o sockets.
2. There is no term for the thing which has a publisher and a subscriber.

I suggest naming the thing a channel. The real-world analogy is a radio channels. When you publish things to a radio channel, you don’t care who’s listening. The number of listeners can be anything from zero to infinite. When listening to a radio channel you can freely switch it on and off (subscribe and unsubscribe).

The term seems to be used already:

• https://github.com/kumavis/node-walkietalkie
• https://github.com/xavi-js/xavi (different context, same meaning)

I have no idea for naming the task sockets yet.

[bergus]

Hm, notice that the term channel is already taken for CSP (see #20), where it has a slightly different meaning. The important differences are:

• In CSP, a "putter" waits for a "taker" (and converse)
• Each bit of information that is put ("published") into a channel is taken out only by a single "subscriber"
• Each bit of information that is put into a channel must be taken out by one consumer.

So they're not exactly broadcast like pub/sub.

That "thing" you describe is not one of these entities with single input and output sockets - instead, there can be any number of publishers and subscribers. The Wikipedia article uses the terms topic, (message) broker and (event) bus, which are fitting better imo.

[kriskowal]

@bergus A CSP channel is what I call a stream. Although this frees up the name “channel” to mean whatever I chose in the context of this article, and although I like the channel metaphor @tomekwi describes, I see no need to confuse. I think I will use “topic” as the composite of “publisher” and “subscriber”. I also need to expand on what distinguishes streams and topics regarding “completeness” (whether messages must be replayed from the beginning through to the end for each consumer), “order” (whether there is an intrinsic order to the messages), and “integrity” (whether a message is guaranteed to be delivered, and therefore whether the producer must wait for the slowest consumer) in addition to “broadcast” vs “unicast”. Without “integrity”, a publisher can have the interface of a synchronous generator, and the consumer can have either a synchronous observer for a “discrete” topic and a synchronous iterator for a “continuous” topic. And so on if I find some time to talk about time series data and logging scenarios in detail.

[tomek-he-him]

I think I will use “topic”

:+1: maybe not as figurative – but it’s definitely a good thing to avoid confusion with CSP.

I also need to expand on…

Thanks for all your effort @kriskowal. The GTOR helped me massively. It’s bull’s eye now that RP is gaining in popularity :)

[kriskowal]

@tomekwi Please link a resource on RP. Perhaps oddly, not sure what that acronym expands to.

[tomek-he-him]

I just meant Reactive Programming :)

[kriskowal]

Ah, of course. Thanks.

[tomek-he-him]

@kriskowal, by the way, I have to take back the claim that “A task has no terms for its i/o sockets.”

It just occured to me that

a task has mostly the same form and features as a promise.

– so it looks like a task has a promise and a resolver as well as a deferred does. You already use these terms for a task anyway, so it seems:

With a task, information flows from the first call to a resolver method […]