...
- Protocol Buffers (from Google) is a strong solution for defining objects (and implementation) that comply with RPC semantics using the strongly-typed binary data format (of protocol buffers); for this reason, generated objects and interfaces comply with a custom data format, they are not plain old objects. Another peculiarity is the lack of support for object inheritance or the removal of field optional/required from version 2 to 3. We've been playing around with some object definitions taken from the FDC3 ContextData codebase, while collecting questions that are still open for debate
- Which version to use? 3 or 2?
- Any best practice to work around inheritance absence?
- Style guide: does the default one suffice, or needs to be extended?
- Nested types: what are the use cases where nested types are better than simple composition?
- Kotlin is a JVM-based programming language, so it’s natively compatible with Java, which provides Interop capabilities for Javascript, C, Swift and others. For Typescript, there’s a Gradle plugin that allows Typescript generation from Kotlin, although it’s maintained by a humble community (3 contributors). Kotlin is also the most trending language in 2018, with a growth of 260% on GitHub public repositories.
- Haxe, similar to Kotlin, but with a wider support for language bindings; the downside is that there is some custom coding needed in order to bind to TypeScript, which is - by far - the most important binding to deliver
...
- A YAML (or similar) format to define object structure, relations between objects and (fine-grained) documentation (#1)
- A language-specific binding generation process - continuously invoked - that reads the format and generates language-specific bindings; this can be achieved in different ways:
- Using TypeScript as reference implementation; other language bindings will be added when requested. This approach probably doesn’t satisfy entirely requirement #3
- Translating YAML to JSON first, then use QuickType to generate language-specific bundles; the main objective of QuickType seems to fit well with FO requirements, but needs some further testing using real specifications and testing integration with FDC3 definitions
- Using language-specific libraries, for example jsonschema2pojo for Java Beans, MakeTypes for Typescript definitions and JsonCSharpClassGenerator for .NET classes
- A YAML to HTML generation to produce (HTML or MarkDown) generation to produce documentation content