JSON RPC / HTTP as internal communication protocol is very expensive and unsecure

[ghost]

We can try three another approarches:

1. Linking statically as Node.js Addon
2. Load dynamically via ffi
3. Write native module via Rust abstraction layer

[ghost]

Also Electron's Using Native Node Modules.

[sjmackenzie]

@dulanov I might be able to take this on (after my FFI experience with sputnikvm).

[ghost]

@sjm which variant do you prefer, dynamically linking via ffi, right?

[sjmackenzie]

@dulanov I cannot say atm but right now, as I'm disliking dynamically linked ffi intensely (I'll suffer through sputnikvm's ffi then smile), though it's probably the best way forward as I can just write ffi code once and it works for different languages. If the alternatives are easier... we need to consider if the easier choice limits other host languages - which defeats our objective. I cannot say just yet.

[ghost]

For node.js there is a static linking option, but ffi i think the fastest and easiest way.

[sjmackenzie]

maybe, we need to choose data types that are suitable for the lowest common denominator language. Say for example C. What I'm looking at is this:

I want to define the interface for sputnikvm in terms of a capnp schema. This allows us to 1) easily evolve it 2) have very clear documentation about input output specs 3) formatted in wire, disk friendly format. The second thing is I want to reduce the schema down to an array of u8 which is a Vec. The trick is being able to reconstitute the original data. So both the sender and receiver convert their data into arrays of uint8_t. For my use case I think this can be constructed and reconstituted by any language with a sufficiently expressive enough capnp compiler plugin.

I would imagine emerald-rs would have similar requirements. There are a few snags, like does the host language have a suitably implemented capnproto compiler plugin. This is a limiting factor.

Deciding not to base the interface on a capnp schema means we need to define it using functions and data types. In this case it would be easier and more languages would be able to access it. .. writing this comment makes me think I should use the same way and not pass an array of uint8_t.

Let me try option 2 on sputnikvm now.

[elaineo]

@sjmackenzie so, what'll it be? Load dynamically via ffi? :)

[ghost]

@elaineo yes, for public beta we want to embedd emerald-rs as dynamic library via ffi.

[gagarin55]

Finally we ended up with native module implemented in Rust