Open4

ygox: Generic Object Exchange APIの設計

okuokuokuoku

GUIライブラリというかLumino https://github.com/jupyterlab/lumino のCバインディングを作りたいけど、流石にひとつひとつのクラスをCにwrapするのは骨が折れるので、ブラウザ側のJavaScriptヒープを操作するgenericなAPIを1つ用意して:

  • Cプログラム: GUI画面をJSONで構築する
  • JavaScript glue: JSONで構築されたGUI画面をLuminoで再現する

という構造にしたい。

okuokuokuoku

Json-Cで十分でない理由

C上のメジャーなJSON実装としてはjson-cがある。

https://github.com/json-c/json-c

が、

  • JSONにはネイティブのシンボル型や64bit整数型がない (json-c自体は整数と浮動小数点を区別し、整数は常に64bitで扱われる)
  • BSON https://bsonspec.org/spec.html で使えるようなblob型が欲しい -- 画像とかを表現するのに必要

といったポイントがある。例えばJavaScriptは BigInt で大きな整数を扱うこともできるので、実用的には(仮にJavaScript上に実装するとしても、) JSONのスーパーセットが必要 と言える。

okuokuokuoku

都度パースにしない理由

殆どのケースではテキスト形式にしたJSONを直接やりとりすれば良いし、仮にJSONで表現できない値を使いたかったとしてもBSONを使うという逃げを打つことはできる。

しかし、GUIアプリで使うことを考えると、生成されたオブジェクトがブラウザ側で変更されるケースが有り、変更されたオブジェクトをリードバックするためのAPIが結局必要になってしまう。

okuokuokuoku

サポートしたい型

  • true false null
  • s32 u32 s64 u64 f32 f64
  • blob - copy, fill, 部分アップデート, 拡大, 切り詰め
  • string - イミュータブル
  • array - copy, fill, 部分アップデート, 拡大, 切り詰め
  • object - string または 整数 をキーにするオブジェクト

文字列をイミュータブル(一度生成したら変更できない)にするのは結構悩ましい。JavaScriptの文字列がイミュータブルなので仕方ないんではないかという気はする。

object のキーに何を許すかも考えどころ。。一旦文字列と整数に絞る。

blobarray はイミュータブルなvariantがあっても良いかもしれない。事前にサイズを確定させておくことでメモリ効率がよくなる。

サブタイプ / メタデータ

string はシンボル(interned/uninterned)、正規表現のようなサブタイプを持たせたい。同様に、数値も日付をサブタイプとして持っても良いんではないか。