MessagePack ep.1 〜文字列とバイナリをめぐる issue 121〜

MessagePack に文字列型を追加するべきか否かをめぐった、長い議論のまとめ。 ep.2に続きます:http://togetter.com/li/467451 issueスレッド121: https://github.com/msgpack/msgpack/issues/121
17
前へ 1 ・・ 47 48
methane @methane

@kazuho @frsyuki まだ気になる点がありました。msgpackを入力し、何らかの中間処理を行って、またmsgpackを出力する類のツールを作る場合についてです。例えばfluentdのin_forward+out_forwardでレコードのグループ化をしないケース

2013-02-23 17:13:49
Kenn Ejima @kenn

@kazuho @frsyuki その懸念は、共同作業の実績と信頼の蓄積がない限り、誰を協力者につけてもありうることだと思いますが、その懸念が大きいなら頑張って単独で行く道もありだとは思います。

2013-02-23 17:13:57
methane @methane

@kazuho @frsyuki Pythonの場合、入力がrawならUTF8でデコードを試み、成功したら出力もrawへ、失敗したら出力はbinaryへと流れます。これは一部データを変更してしまっているものの、 may be string が実は string じゃなかった

2013-02-23 17:15:45
methane @methane

@kazuho @frsyuki という意味である程度妥当になると思います。 Ruby の場合、アンパック時に元がbinary型だったかどうかの情報を何らかの手段でStringインスタンスに付与できれば、同じ型で出力出来ます。ですがphpはツライ。(Perlは判らない)

2013-02-23 17:17:20
Kenn Ejima @kenn

@frsyuki まずすぐに言えることで1点だけ。「rawを新設」は混乱を助長すると思うので、この機会にrawはやめて、byte/binary/blobなど別の名前をつけたほうが良いと思っています。rawといえば旧フォーマットのrawをさすべき。互換性説明がややこしくならない。

2013-02-23 17:17:54
methane @methane

@kazuho @frsyuki もし php で msgpack の中間処理を行うことになった場合、入力のrawも新設binaryも文字列として出力する素直なデコーダを使うと、出力にはbinary情報が抜け落ちてしまいます。デコーダに対する推奨として、

2013-02-23 17:19:13
Sadayuki Furuhashi @frsyuki

@kenn 命名の問題は確かに存在します。Rawが良いか、Binaryが良いか、Blob? Stringもどうするか。 @methane @kazuho

2013-02-23 17:19:14
Kenn Ejima @kenn

@frsyuki @methane @kazuho stringはstringでおそらく異論のないことと思います。string派のひとたちを混乱させないマーケ的要素が第一義なので。

2013-02-23 17:20:09
Kenn Ejima @kenn

@kazuho @frsyuki @methane 自分の意見いってなかったですね、ぼくも binary +1 です。

2013-02-23 17:20:55
SKS rep @repeatedly

@frsyuki @kazuho @kenn @methane stringはthriftもjsonも使っているし,これがベストと思われ.blobよりもbinaryの方が個人的にはわかりやすい

2013-02-23 17:21:27
Sadayuki Furuhashi @frsyuki

@methane なるほど。Rubyのデコーダでは、新設Raw型を受け取ったときは、encodingにASCII-8BITを付けると思います。StringならvalidationなしでUTF-8を付けるのは従来通り。 @kazuho @kenn

2013-02-23 17:21:48
methane @methane

@kazuho @frsyuki 文字列にバイナリかどうかの付加情報を持たせられない場合は、文字列の代わりに文字列をメンバに持つ MsgpackBinary クラスのインスタンスを返すようなオプションがあるといいのかなと思いました。ただし、全ての言語で中間処理が行いたい訳では

2013-02-23 17:22:03
Sadayuki Furuhashi @frsyuki

@kazuho @kenn @methane @repeatedly binary++。型=Binary、フォーマット=binary 8, binary 16, binary 32ですね。

2013-02-23 17:22:28
methane @methane

@kazuho @frsyuki すべての言語が #msgpack の中間処理を行いたいとは限らないので、あくまでも推奨というかオプションみたいな形で。

2013-02-23 17:23:26
Sadayuki Furuhashi @frsyuki

@methane ふーむ。エンコーダの方ですが、区別が曖昧な言語においても、バイナリをBinary型で保存する方法が提供されないと困るのは事実で、これの実装はSHOULDと言えます。 @kazuho @kenn

2013-02-23 17:29:50
Sadayuki Furuhashi @frsyuki

@methane デコーダの方で、受け取ったのがBinaryかStringかを区別する方法がないと、困るケースがある…ですね。確かに。中間処理を行いたい場合。 @kazuho

2013-02-23 17:30:34
Sadayuki Furuhashi @frsyuki

アップデート。 "msgpackの変更案について" http://t.co/ZdanjZJ61E

2013-02-23 17:38:36
Sadayuki Furuhashi @frsyuki

@kuenishi これ見てもらえます…? いずれにしてもまだ issue 121 上では議論が必要ですが、このタイミングの方がはるかに議論しやすいと思います "msgpackの変更案について" http://t.co/ZdanjZJ61E

2013-02-23 17:45:07
kuenishi @kuenishi

@frsyuki ごめん、ちょっと時間がなくてナナメ読みだけど、基本的に賛成。バージョンは1.1がいいと思う。Erlangも実装できると思う。

2013-02-23 18:04:45
前へ 1 ・・ 47 48