Medium-independent communication

[byorgey]

Currently we have several vague ideas/starts towards communication of various kinds:

• We now have I/O cables (74ad23e) which we don't really use for anything yet other than as an ingredient for ADT calculators, but the idea is that they will let you plug into nearby robots/other things (ATMs? other computer systems?) and communicate with them. See also Use placed cables as communication channels #739 .
• We also have say/listen; I imagine you might use this to communicate with aliens (Ideas for encounters with alien actors/robots #218).
• We are also contemplating some kind of wireless communication through antenna devices or whatever (Inter-robot communication #94).

I'm wondering if we could somehow unify all these things so you could program communication protocols independently of the underlying transmission medium? I don't yet know what that would look like, but I was inspired thinking about @fryguybob 's comments re "modularity" in #218.

[xsebek]

Heh, maybe we could add world: chan text, so that say == broadcast world. Basically the same thing as stdout in most programming languages.

To me channel is the most general idea and even physical wires (or in our case IO cables) are a kind of channel or communication medium.

[xsebek]

I made a separate Issue for the cable communication, thanks for bringing it up! 👍

• Use placed cables as communication channels #739

[byorgey]

Yes, I love the idea of making chan the general underlying idea, and world : chan text.

[byorgey]

In thinking this over, the big issue I keep coming back to is synchronization, especially when multiple readers and/or writers are involved. When you read from a channel, what do you get? Does a channel act like a queue, where it holds on to previous values? Or is it more like a broadcast mechanism?

• If a channel is like a queue, such that sending over the channel enqueues a message and reading dequeues one, it makes asynchronous communication easy, since you can send whenever you like, and the intended recipient can come along and read whenever they like.
  • However, it means you can't really have multiple readers with one sender. You would have to simulate this by having e.g. have a single reader that passes along messages to multiple others.
• On the other hand, a channel could just be a broadcast mechanism: if no one is listening at the time that you send a message, then the message is gone and no one can ever receive it.
  • This makes supporting multiple listeners trivial. However it makes asynchronous communication more difficult. You would have to e.g. create a dedicated listener robot to sit there listening all the time.

Edit: I think channels should probably just be a broadcast mechanism. That would be simpler and it's what cables/channels are really like. It also fits the aesthetic that we provide simple low-level mechanisms, and then you have to build more sophisticated/abstract things on top. See some additional relevant thoughts/comments here: #739 (comment) , in particular the idea to add an int parameter to the write or send command to determine how long to keep the value on the wire/channel.