IDL approach

[filmil]

Complementary to #1.

In case it is useful, we could consider using an IDL to auto-generate libraries from a common core implementation.

Pros:

• No need to transpile.

Cons:

• Won't work for languages that don't use FFI.

[sffc]

Related: http://bit.ly/omnicu-cross-lang-design

My experience is that IDL-like abstractions create more confusion than they're worth. The API surface in each of our target languages is going to look a little bit different. Trying to make an IDL do what we want is likely to be more engineering effort than just writing the API surface directly.

That being said, the advantage of an automated way of generating the "glue code" between clients and the FFI is that we can add new APIs in one place and automatically generate bindings in our target languages.

[sffc]

@filmil, can you submit some documentation about this to the repo for longevity, such that we can close this issue? Thanks.

[filmil]

The goal here was to explore if indeed the glue code could be autogenerated, in a similar way how language-specific code is generated from protobufs for example. FFI bindings are tedious to maintain manually, so a way to get most of that tedium autogenerated looked like it could be a good thing.

[sffc]

Can you add an FAQ to charter.md, or a section to wrapper-layer.md, describing this approach?

[sffc]

I added a mention of this to wrapper-layer.md in #28.

[filmil]

Unassigned myself since you already have #28