Closed kiliankoe closed 7 years ago
Nevermind, I'm an idiot 🙃
See readme.md
JSON and ndjson only
In fact, your question is relevant. The idea of @juliuste and me was to use it as an exchange format between JS libs as well, but since JSON means JavaScript Object Notation, that seemed obvious to us. Maybe we should clarify the readme.
I spent a few minutes this morning writing a Swift lib including the types here including functionality to parse JSON into them. Only when writing tests I realized that the examples weren't json, but js objects^^ Doesn't make a difference regarding the content, just a bit regarding the specified syntax, but that's not an issue.
The code blocks in the "spec" (docs/readme.md
) have been JS for now for a technical reason: JS allows comments and IMO has a better readability.
note that we might want to add proper machine-readable type definitions anyways, e.g. in the form of protocol buffer markup (#3). i'd be happy to include easily editable, cross-platform (& cross-language) definitions!
I've come to label json source on GH as js so that comments aren't marked as invalid syntax^^
Protobuf definitions sound awesome! Not having much experience with their definition language though I'm wondering how possible it is to define those dynamic reference fields, which can be either a string or an object (sometimes even different objects).
Protobuf definitions sound awesome! Not having much experience with their definition language though I'm wondering how possible it is to define those dynamic reference fields, which can be either a string or an object (sometimes even different objects).
From my little experience and quickly looking at the guide, it should be possible.
Is this format intended to be used a transport format, e.g. as JSON, as well? Or just as a common API between several JS modules?