Redesign Brain Dump

Literally thinking out loud on Slack tonight:

We should be able to use channels outside of the context of CH code
that was 1
2. we should be able to monitor channels, outside of CH code

3. the semantics of how this works will depend on the channel implementation
4. local and remote channels have a different interface/API for using them
5. none of that requires a node controller, or any actors.
5. update: none of that requires a node controller for local channels, or any actors in either case
6. I personally think an actor system is very useful for building CH, so we want one of those
7. the semantics should match the current semantics - but we’ll come back to that
8. a local actor system does not need a network listener loop
8b. a local actor system does need at least one infrastructure `forkIO` thread to deal with monitors and the like
9. a local actor system can take advantage of either N-reader<>1-Writer STM transactions to look up destinations for local send
9b. a local actor system /might/ even be able to avoid serialising access to, for example, monitoring and linking records
9c. I’ll have to look and think very carefully if this will break the semantics, but I do not think it will
9d. I will be writing a wiki page on this subject shortly anyway
10. with a local actor system in place, that uses STM to communicate between actors, and supports initially only typed channels…

qnikst [22:27]
=

hyperthunk [22:27]
10a. we can write a node controller process that manages the node
11. we can spawn additional processes for each remote node connection
12. we can provide an API for local actors to send to remote actors
13. this API will be *different* to the local API - no location transparency
14. we can add a special channel type to deal with the runtime type binding that cloud haskell currently does
15. we can write a layer over all these things to make the distributed-process API remain as it is now
that’s a brain dump
for now