アカウント名:
パスワード:
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 の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。
protocol buffers のドキュメントを斜め読みしてみました。
> protocol buffersではすべてのデータにはフィールド番号がついていますので、 フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。 プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。
> protocol buffersではすべてのデータにはフィールド番号がついていますので、 フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。
何か誤解しているように思います。 .proto ファイルの language guide [google.com] によれば、 .proto ファイルでは各フィールドに明示的にタグ (メッセージ中のフィールドを識別する番号) を指定します。 #1383160 [srad.jp] の人が「フィールド番号」と呼んでいるものは protocol buffers のタグと同一だと思います。デコーダーは符号化されたデータの中のタグを見て、自分の知らないタグが付いたフィールドをスキップするようで、これによって将来フィールドが追加された場合に新しいデータを古いデコーダーに読ませても大丈夫になっているようです。
また、 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:XMLのコストが高いのはわかるが (スコア:0)
私の記憶が確かならば、XDRやASN.1は構造体のフィールド名などは保持せず、ただのシリアライズだったはずです。
これではフィールドが変更されると互換性がなくなるでしょう。
スキーマというほどのものではないですが、protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
いずれにしろ8ビット機時代を思わせる原始的なフォーマットですが、十分実用的で高性能というのはなかなか気の利いた話で、
Googleのような影響力のあるところが公開したのは喜ばしいことだと思います。
Re:XMLのコストが高いのはわかるが (スコア:1)
説明ありがとうございます。よくわかりました。スキーマと聞いてフィールド名や型の情報を連想してしまい、そんなの protocol buffers でも送信されないよなあ、もしかして .proto ファイルのことか? などと少し混乱しかけていました。
たしかにそうですね。
今までも小型で高性能で拡張性のあるシリアライズ方式が必要な場面ではあちこちで似たようなシリアライズ方式が考案されコードが書かれてきたのでしょうから、 protocol buffers の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。
Re:XMLのコストが高いのはわかるが (スコア:1)
これではフィールドが変更されると互換性がなくなるでしょう。
ASN.1では抽象構文自体にメッセージの将来的拡張の可能性を明記するので、拡張後のデコーダなら拡張前とはデータに互換性があり、逆の場合は非互換です。
> protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。
（公開されているジェネレータを使わずにエンコードだけ借りるなら話は別だけど）
Re:XMLのコストが高いのはわかるが (スコア:1)
protocol buffers のドキュメントを斜め読みしてみました。
何か誤解しているように思います。 .proto ファイルの language guide [google.com] によれば、 .proto ファイルでは各フィールドに明示的にタグ (メッセージ中のフィールドを識別する番号) を指定します。 #1383160 [srad.jp] の人が「フィールド番号」と呼んでいるものは protocol buffers のタグと同一だと思います。デコーダーは符号化されたデータの中のタグを見て、自分の知らないタグが付いたフィールドをスキップするようで、これによって将来フィールドが追加された場合に新しいデータを古いデコーダーに読ませても大丈夫になっているようです。
また、 protocol buffers のタグは一つのメッセージの中でしか一意でないので、タグを見てメッセージを判別することはできません。デコーダーを呼び出す前に、これから復号しようとするメッセージの型を知っている必要があります。