> Example makes it look like library is transport-agnostic. Seems like we could
> have both ends host their own APIs and one end could call another's APIs and
> we just pass messages between them.
The server is transport agnostic. The dispatch function that it generates takes
a JSON object, either parsed or in string form. That object can come from
anywhere, and I'm open to including more helper functions to help with
different transport layers.
The client is, at the moment, much more restricted. Right now, the client only
generates HTTP requests and only works in the JavaScript target. A native
client is something I was already planning on adding, and shouldn't be too
difficult to support. I just need to decide on a clean mechanism for
determining if a service should generate a server or client.
I hadn't thought about making the client transport agnostic, but I'm open
adding it :) Off the top of my head, the easiest way I can think to support
arbitrary transport layers while keeping the nice auto-generation of the client
is to allow users to pass a transport function to the macro. So the macro
definition could look something like:
rpc Hello, myTransportFunction:
Run
where `myTransportFunction` takes a JSON object (still autogenerated by the
client) and is responsible for sending it to the server.
Would this work for your purposes? If so, I'd be happy to write up the issue
and start development! If there's any other tweaks that would make this more
usable, please let me know.
