I'm building a new general purpose RPC mechanism to replace the current HTTP/REST technology, as well as the whole TCP port thing. What service you're talking to on the host will be completely hidden from prying eyes, and unblockable.
You call an endpoint anywhere on the planet and give the name of the service you want, which then gives you access to that service's published API (similar to how you'd use import and gain access to a library's API).
To start, it will operate over port 80/443 to allow seamless integration into the current world infrastructure, but I'm also hoping that in maybe 10 years it could replace HTTPS entirely, possibly even TCP.
The first step is an encoding mechanism that supports the most common data types natively, which I've defined here [1], and am currently writing implementations for in go. It's a parallel text and binary encoding so that we don't waste so much time generating bloated text that's just going to be machine-parsed at the other end, but also allows converting on-demand to a text format that humans can read/write. I ended up developing new encoding schemes for floating point values [2] and dates [3] to use in the binary format.
The next layer above that is a generic streaming protocol [4], which can operate on top of anything from i2c to full-on HTTP(S), and supports encryption. It's designed to be as non-chatty as possible so that for many applications, you simply open the connection and start talking without even waiting for the other side's acknowledgement. It supports bi-directional asynchronous message sending with chunking and optional acknowledgement on a per-message basis, with tuneable, negotiable message header size.
The final layer will be the RPC implementation itself. I want this as a thin layer on top of streamux because many of the projects I have in mind don't need full-on RPC. This part is still only in my head, but if I've designed the lower layers correctly, it should be pretty thin.
You call an endpoint anywhere on the planet and give the name of the service you want, which then gives you access to that service's published API (similar to how you'd use import and gain access to a library's API).
To start, it will operate over port 80/443 to allow seamless integration into the current world infrastructure, but I'm also hoping that in maybe 10 years it could replace HTTPS entirely, possibly even TCP.
The first step is an encoding mechanism that supports the most common data types natively, which I've defined here [1], and am currently writing implementations for in go. It's a parallel text and binary encoding so that we don't waste so much time generating bloated text that's just going to be machine-parsed at the other end, but also allows converting on-demand to a text format that humans can read/write. I ended up developing new encoding schemes for floating point values [2] and dates [3] to use in the binary format.
The next layer above that is a generic streaming protocol [4], which can operate on top of anything from i2c to full-on HTTP(S), and supports encryption. It's designed to be as non-chatty as possible so that for many applications, you simply open the connection and start talking without even waiting for the other side's acknowledgement. It supports bi-directional asynchronous message sending with chunking and optional acknowledgement on a per-message basis, with tuneable, negotiable message header size.
The final layer will be the RPC implementation itself. I want this as a thin layer on top of streamux because many of the projects I have in mind don't need full-on RPC. This part is still only in my head, but if I've designed the lower layers correctly, it should be pretty thin.
[1] https://github.com/kstenerud/concise-encoding
[2] https://github.com/kstenerud/compact-float
[3] https://github.com/kstenerud/compact-time
[4] https://github.com/kstenerud/streamux