メニュー

2013年3月1日

msgpackの話題

近頃盛り上がっているmsgpackの話題についてです。

文字列型の追加について


事の発端はこのIssue。
https://github.com/msgpack/msgpack/issues/121

「Pythonのライブラリでpackしたデータをunpackしたら元のデータと違うデータになった」というIssueです。これは、Pythonのユニコード文字列をpackしていますが、msgpackには文字列という型はないので、戻せなかったことが原因です。

上記のIssueは、msgpack自体の仕様というよりは、ユニコード文字列を受け取って変換していたPython版ライブラリのバグといえるでしょう。

msgpackはさまざまな言語が相互にやりとりするために考案されたものなので、基本的な型だけを定義しています。文字列はRawというバイナリ列に格納されます。文字列はバイナリ列の一種なので、バイナリ列のコンテナがあれば、文字列はそこにそのまま入れることが出来ます。

msgpackが文字列型を定義しなかったのは相互運用性のためには当然かと思います。

例えばPHPやPython2では、文字列もバイナリ列も同じ型です。
（Pythonは別途ユニコード文字列はありますが、通常の文字列はバイナリ列と同じです）

多様な言語が存在するので、もし仮に文字列型を定義していた場合、言語によっては「データを文字列型とバイナリ列型のどっちにいれていいか分からないよ！」となってしまいます。

msgpackのデータを受け取り、そこから、その言語の文字列型としてデータを取り出したい場合は、アプリケーションが自分で変換する必要がありますが、会話しているアプリケーション同士は、データが何であるかは知っているので、アプリケーションが変換すればよいのです。

ところが、それが面倒なので、やはりライブラリ側で変換してよ、という要望が出てきました（過去にもあったようです）。

msgpackの作者である @frsyuki さんや各言語のライブラリ作者の方々は、上記のような理由から文字列型がない理由や、文字列型を追加した場合の問題・課題を説明しますが、やはり文字列型が欲しいという強い要望もあり、検討に入りました。

ここで、一部の人が「文字列のエンコード・デコードなんて20行で書けるだろ。それが出来ないならコードなんて書くな！」「bullsh*t」「f*ck」のような暴言を吐いたことも、炎上の一因とも言えます。

僕はTwitterで炎上していることを知り、GitHubの当該Issueを読んだところ、あまりにもmsgpackの作者である @frsyuki さんに対して敬意を欠いた暴言を見るにつけ、ついついコメントをしてしまいました。（なお、僕はmsgpackのユーザであり、開発者ではありません）
「文字列型があると便利だと思う。でも文字列とバイナリ列を区別しない言語もある。どうやって文字列型を追加したらいいと思う？」
要は、文句ばかりいってないで、相互運用性と互換性維持を考えた仕様を出せよ、と。

ガン無視でした……。

「仕様とか分からなけど、とくかく文字列型を追加すればいいんだよ！」ということですか、そうですか。

その後、他の人からBinaryPack を提案するコメントがあったので、僕は「後方互換性は壊さないで欲しい。BinaryPack は後方互換性が壊れるので困る」と GitHub にコメントしています。
※BinaryPackはmsgpackの派生で、文字列型が追加されていますが、互換性がありません

この時、僕がすぐに考えたのは、以下の様な仕様でした。
結局、@frsyuki さんや各言語のライブラリ作者で議論して、いくつかの提案がなされています。いずれにせよ、後方互換性は守られそうなので、ひとまず安心しているところです。

仕様については、こちらで議論されています。
https://github.com/msgpack/msgpack/issues/128


IETFについて


さて、この話題にはもうひとつの側面があり、それはIETFです。

去る2012/10/11に、IETFで「JSON-like representation format」のドラフトが投稿されています。
http://tools.ietf.org/html/draft-bormann-apparea-bpack-00

ここに、MessagePackとMessagePackの派生であるBinaryPackの名前が出てきます。

これはmsgpack作者である @frsyuki さんによるものではなく、cabo さんという方によるものです。しかも、知らぬ間に行われていました。

msgpackはオープンソースで派生するのは自由なので、それ自体はありかなと思います（もちろん、事前に話があったほうがいいとは思いますが）。また、msgpack自体の標準化ではなく、JSON関連の標準化の一部のようです。

仕様が標準化されるのはメリットがあると思いますが、GitHubで文字列について議論している段階でIETFでも仕様について議論が並行するとなると、いろいろ問題がありそうだ、ということで問題になっています。

  • コミュニティ側とIETFで仕様が異なったらどうするの？
  • IETFの議論に参加するには時間もコストもかかりそうで困る

といったところです。

IETF問題は今も継続していますが、僕が見た範囲でのコミュニティ側の空気としては「IETF自体には反対でもないが、いまは新仕様を議論しており、時期尚早である」というところかなと思います。

また、IETFにドラフトを出した cabo さんによる新しいIssueも登録されました。
「MessagePack should be developed in an open process」
https://github.com/msgpack/msgpack/issues/129

「もっとオープンなプロセスで開発しよう」ということですが、GitHub自体は比較的オープンであり、仕様策定に関しては @frsyuki さんからガイドラインも提示されているので、日本人以外の人からも含めて、総ツッコミされています。

僕としては、cabo さんを経由して標準化させつつ、その仕様については @frsyuki さんがコントロール出来る状態になればいいかなと思っています。
要は、仕様は決めていくから、あとはそのままIETFに投げてくれって方向で。

さて、今後どうなるんでしょう……。

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)