Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss new host implementation #103

Open
garritfra opened this issue Jan 4, 2020 · 3 comments
Open

Discuss new host implementation #103

garritfra opened this issue Jan 4, 2020 · 3 comments
Labels
Discussion Discussions going on

Comments

@garritfra
Copy link
Member

garritfra commented Jan 4, 2020

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 garritfra added the Discussion Discussions going on label Jan 4, 2020
@garritfra
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Discussions going on
Projects
None yet
Development

No branches or pull requests

2 participants