Skip to content

Instantly share code, notes, and snippets.

@unnonouno
Created September 25, 2012 06:10
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save unnonouno/3780251 to your computer and use it in GitHub Desktop.
Save unnonouno/3780251 to your computer and use it in GitHub Desktop.
設定をどういう形式で与えるのが良いか

検討事項

  • 表現力がどれくらいあるか(型、デフォルト、オプショナル)
  • 設定を書きやすいか(コメントなど)
  • 仕様を記述できるか(スキーマを記述する方法があるか)
  • スキーマの検証ができるか

案1: JSON

pficommon JSONで実装。スキーマはstructで記述できる。可読なスキーマをjson schemeで記述。

メリット

  • 型、オプショナルは表現できる
  • 設定は人間可読
  • structでスキーマを簡単に表現できる
  • JSON schemeでフォーマルに書くこともできる
  • json_castで検証と変換が同時に出来る

デメリット

  • デフォルト値を表現しづらい
  • コメントを書けない
  • json scheme自体は読みづらい、一般化してない?

案2: msgpack + msgpack-idl

msgpack objectで実装。可読なスキーマがidlで記述できる。

メリット

  • 型、オプショナル、デフォルトは表現できる
  • msgpack-idlでスキーマを簡単に表現できる
  • mpidlで検証と変換がある程度できる

デメリット

  • 設定を記述する方法がない
  • オブジェクトの表現がtupleになってしまう
  • mpidlでの検証は実装が部分的

案3: map<string, string>

std::mapで実装。表現力不足は文字列表現で補う。

メリット

  • 依存ライブラリはない
  • 設定記述はJSONなどを経由

デメリット

  • 型、デフォルト値など、表現力は無い
  • スキーマの記述、仕様の記述ができない

案4: yaml

libyamlなどで実装。

メリット

  • 型を記述できる、表現力はJSONと同じくらい
  • コメントを書ける
  • ライブラリを利用できる

デメリット

  • schemeを記述できない?
  • 自動検証ができない?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment