アカウント名:
パスワード:
Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。
XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。
どちらもCで使われるデータ構造(struct含む)に毛が生えたようなものをそのままシリアライズしているので、 スキーマが存在しません。 それでだめだったんでしょう。
もしよければ、「スキーマが存在しないので駄目」というのをもう少し詳しく教えてもらえないでしょうか。
protocol buffers は、プログラムのバージョンが上がって新しい形式のデータと古い形式のデータを話すプログラムが混在しても大丈夫なように設計されているようです。 XDR や ASN.1 はそうなっていないという意味でしょうか。
説明ありがとうございます。よくわかりました。スキーマと聞いてフィールド名や型の情報を連想してしまい、そんなの protocol buffers でも送信されないよなあ、もしかして .proto ファイルのことか? などと少し混乱しかけていました。
スキーマというほどのものではないですが、protocol buffersではすべてのデータにはフィールド番号がついていますので、 フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
たしかにそうですね。
いずれにしろ8ビット機時代を思わせる原始的なフォーマットですが、十分実用的で高性能というのはなかなか気の利いた話で、 Googleのような影響力のあるところが公開したのは喜ばしいことだと思います。
今までも小型で高性能で拡張性のあるシリアライズ方式が必要な場面ではあちこちで似たようなシリアライズ方式が考案されコードが書かれてきたのでしょうから、 protocol buffers の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
XMLのコストが高いのはわかるが (スコア:0)
Re: (スコア:0)
君のお腹が一杯になると、何か解決するの？
君の許容量が低いだけ？
恐らく、こういったのはシステム全体を含めた上手い解決策がでるまで、
何回でも何年でもやり続ける作業だと思います。
その解決策が使えるのは、せいぜい数年かもしれませんが…
Re: (スコア:2, すばらしい洞察)
YAML や JSON じゃだめなの？ 正直，XDR とか ASN でもいいと思うんだけど…
XML 対 非XML という対比については分かりやすいのだけど，非 XML 同士では流派の
違いというか，審美観の問題になっている気がするです．
Re: (スコア:2, 参考になる)
Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。
XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。
Re: (スコア:1, 参考になる)
どちらもCで使われるデータ構造(struct含む)に毛が生えたようなものをそのままシリアライズしているので、
スキーマが存在しません。
それでだめだったんでしょう。
Re: (スコア:1)
もしよければ、「スキーマが存在しないので駄目」というのをもう少し詳しく教えてもらえないでしょうか。
protocol buffers は、プログラムのバージョンが上がって新しい形式のデータと古い形式のデータを話すプログラムが混在しても大丈夫なように設計されているようです。 XDR や ASN.1 はそうなっていないという意味でしょうか。
Re: (スコア:0)
私の記憶が確かならば、XDRやASN.1は構造体のフィールド名などは保持せず、ただのシリアライズだったはずです。
これではフィールドが変更されると互換性がなくなるでしょう。
スキーマというほどのものではないですが、protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
いずれにしろ8ビット機時代を思わせる原始的なフォーマットですが、十分実用的で高性能というのはなかなか気の利いた話で、
Googleのような影響力のあるところが公開したのは喜ばしいことだと思います。
Re:XMLのコストが高いのはわかるが (スコア:1)
説明ありがとうございます。よくわかりました。スキーマと聞いてフィールド名や型の情報を連想してしまい、そんなの protocol buffers でも送信されないよなあ、もしかして .proto ファイルのことか? などと少し混乱しかけていました。
たしかにそうですね。
今までも小型で高性能で拡張性のあるシリアライズ方式が必要な場面ではあちこちで似たようなシリアライズ方式が考案されコードが書かれてきたのでしょうから、 protocol buffers の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。