-
- いいね！1
Sadayuki Furuhashi
@frsyuki
@nalsh 「文字列」を扱うコードって、どのエンコーディングを使うかや、ノーマライズやバリデーションの方法が、アプリケーション依存だと思うのですよ。シリアライザに任せずに、バイト列とエンコーディング方法をtupleで受け渡して、その扱いはアプリでよろしくやればいい。
2013-02-05 23:58:19
成瀬
@nalsh
@frsyuki はい、「fluentd周辺は『文字列』を扱う必要が無い」ってのは正しいと思います。出所はそれが何者か知ってるだろうから、下手にいじらない方がいい、と。
2013-02-06 00:05:25
Sadayuki Furuhashi
@frsyuki
追加するとしたらどうするかが重要か。String型と validated UTF-8 表現形式を入れるか、String型は入れずにRaw型に validated UTF-8 表現形式を追加するか。Java実装的には後者の方が良い。動的型付け言語だと前者かなぁ。
2013-02-06 08:59:36
Sadayuki Furuhashi
@frsyuki
String型を追加するのは、たぶんきっとマズイなぁ。C++やRubyと通信したときに混乱すると思う。仕様上はRaw型ということにしておいて、ライブラリは互いを変換する仕組みを提供するべき、とした方が良いと思う。大抵の言語では組み込みライブラリでできるが、Cにはない。
2013-02-06 09:15:00
Sadayuki Furuhashi
@frsyuki
どっちもRaw型ということは、シリアライズするときに文字列を FixRaw 表現形式でシリアライズしても良いし、バイト列を validated UTF-8 でシリアライズしても正当だということになる。その区別はデシリアライズ側の仕事。これである程度の後方互換性を保てる。
2013-02-06 09:16:39
kuenishi
@kuenishi
Unicode型の追加要望なんてのはPythonistaとRubyistの独善である。C++でstring<wchar_t>なんて使われたらどうするんだ
2013-02-06 09:18:50
Sadayuki Furuhashi
@frsyuki
あーバイト列を validated UTF-8 でシリアライズするのは表現形式の仕様に反するからダメだな。文字列を FixRaw や raw16 はあり得るけど、バイト列を validated UTF-8 は無い。デシリアライザはこのあたりを利用する。
2013-02-06 09:20:36
Sadayuki Furuhashi
@frsyuki
@kuenishi ぃゃRubyには（文化的な理由で）要らないのですよ。（最近の）JavaScripterは結構欲しがる模様。
2013-02-06 09:21:38
Sadayuki Furuhashi
@frsyuki
データ表現の型システムと特定言語の型システムの射影がうまく自動化できないというだけで、全言語でうまく行くわけ無いし。設計時にC++に寄せた結果がこれだよ。（愚痴
2013-02-06 09:22:50
Sadayuki Furuhashi
@frsyuki
@kuenishi いまの個人的な感想は結構複雑で、文字列型は入れなくても良いと思っているのですが、実装がforkするのもイヤなんですよね。
2013-02-06 09:29:44
Sadayuki Furuhashi
@frsyuki
@kuenishi 文字列を入れたいヤツは入れればいいが、相互運用性は（現時点では）保証しない。が、変化しないのは必ずしも良いことだとは思わないので、誰か人柱になって試してくれる分には歓迎する。自分ではメリットを感じないのでやらないし、他人を巻き込むつもりもないが、と。
2013-02-06 09:33:01
Sadayuki Furuhashi
@frsyuki
@kuenishi そこであり得る現実的な解決策は、フォーマットを拡張できるようにする仕様を追加し、独自拡張が入った実装もMessagePackと名乗れるようにする方法。オプションで切れる（あるいは、そのライブラリ自体を使わない）という選択肢が用意されているなら、問題ない。
2013-02-06 09:34:03
Sadayuki Furuhashi
@frsyuki
@kuenishi そんな中でイケてる方法がでてきたり、その独自拡張がデファクトになったら、本体に取り込めばいい。独自拡張が可能な仕様があれば、msgpack-javaや-rubyでも文字列表現形式を実装しても良いなぁと思ってます。実験的に。もちろんデフォルトは無効。
2013-02-06 09:37:09
Sadayuki Furuhashi
@frsyuki
@nalsh @kuenishi そのendcoding情報に適合しないバイト列が含まれていた場合、デシリアライズ自体をエラーで止めるべきか（=デシリアライザでvalidationを行う）、デシリアライズは成功して、不正なバイト列が含まれるStringを復元するべきか…
2013-02-06 09:40:00
Sadayuki Furuhashi
@frsyuki
保存しちゃったデータが復元不可能になったら、それは非常に困るので、encoding情報（特定のバイト列が不正になるようなencoding, UTF-8とか）を付加するのであれば、シリアライザ側でもvalidationが欲しくて、不正なバイト列はシリアライズできないようにするべき。
2013-02-06 09:42:21
成瀬
@nalsh
@frsyuki @kuenishi バイト列と文字列が別の内部表現の言語だと欲しいかもしれませんね。JavaScriptのUint8Array/Stringとか、JavaやC#のbyte[]/String、Pythonのbytes/str/unicodeを自力変換はだるそう
2013-02-06 09:43:28
Sadayuki Furuhashi
@frsyuki
デシリアライザはそれを前提として、不正なバイト列はエラーで弾く。ただしデータは必ずしも信用できないので、デシリアライズ側でもvalidationを行う。これはデータは信頼できると仮定して性能を稼ぎたいケースもあり得るのでオプションでも良い。
2013-02-06 09:44:21
Sadayuki Furuhashi
@frsyuki
となるとたぶん、複数のエンコーディングをサポートするとvalidationの実装がキツくなって他言語対応が難しくなると、UTF-8 固定がいいんじゃないかな…
2013-02-06 09:46:37
成瀬
@nalsh
@frsyuki @kuenishi デシリアライザってアプリケーションからfluentd経由で飛んでくるMessagePackされたログをストレージにつっこむ手前で動くって理解であってます?
2013-02-06 09:47:30