Discuss new host implementation

[garritfra]

This issues just serves as a mental note that the new host implementation will need to be implemented in v0.2.0.

Further discussions on this topic should be documented here.

[garritfra]

We discussed that autobahn would be a great fit for this task. It is quite large though, so it might need to be replaced in the future

[pouya-eghbali]

autobahn is really nice, but it's huge. What we need is pub/sub and some basic RPC. Probably, in the future, host should support several backends/transports, for example if someone wants to make an addon for socket.io or sockjs or some custom library, they should be able to do it.

Maybe we can implement host using autobahn now, then we can add the custom backend for host feature, and then implement a small and clean library as our official host backend. I propose we have a package/module named host:

import host from "host"

@host /api/v1.0.0/add
fn add a b:
  a + b

This way host won't be added as dependency to projects that do not need it. And in the cli, for clio host command, we can do:

const server = require("/build/node_modules/host/server")
const main = require("/build/main.clio.js")
server(main)

Or something like that.

[pouya-eghbali]

I made an entire RPC stack for the new Clio. It has concepts like Transports, Executors, Workers, Clients, Servers, Dispatcher and etc. It's a modular design, the Dispatcher acts as a Hub, it accepts Server Transports and accepts connections using that Transport, it also registers and manages the Workers who request to be registered through one of the Transports. This way a TCP client can communicate with a WebSocket client with no issues, in other words you can have TCP/UDP/WS/WT/WW... workers and clients all communicating with each other without worrying about communication protocols.

I'm going to keep this open for further discussions, I'll close this once we have our RFC system established.