What was the rationale behind choosing MessagePack? Protobuf, in my opinion, would have been much better a choice. It has library support for a great many languages (including Rust, I’m guessing). With it, one could have neatly defined all of a happ’s extern functions in a .proto file, then have implemented the server code in the Rust DNA. Client code could have been implemented in almost any language (as I said, Protobufs support many languages) with almost zero tweakings. Plus for Holo (a scenario in which the protobuf/GRPC client and server would reside on different machines) you’d have got all the benefits of GRPC’s non-blocking bidirectional streaming. And yeah, if memory serves well, functions (in protobuf/GRPC) can return a stream of data, thanks to which, implementing something like live events or notifications is a piece of cake, so no need for your hackerish workaround called ‘Signals’. As for efficiency, nothing beats protobufs (not even msgpack). Msgpack over WebSockets requires client/UI developers to have to duplicate the structural details of the invariants (the input/output parameters of hdk extern functions). Having to ‘compulsively’ check the spelling of the extern functions’ parameter with what they declared in Rust can cause them severe mental stress (besides the whole task being completely redundant and utterly pointless). The more the errors can be moved to compile-time, the better, or so the saying goes. A move to protobufs would greatly reduce the pain and suffering in the world.
[cc @thedavidmeister]