MessagePack, BufferPacker, StreamPacker の設計について

Sadayuki Furuhashi @frsyuki

BufferPackerとStreamPackerを分けるのは微妙で、たぶんそもそもStreamPackerで、あと BufferPacker extends Packer にするのが良いのではないかという案が1点と

Sadayuki Furuhashi @frsyuki

あと JSON extends MessagePack が厳しくて（createBufferUnpacker）、現状のBufferUnpackerのインタフェースは全機能を実装するのが難しい。特にfeed。状態遷移マシンベースのデシリアライザが必須。

Sadayuki Furuhashi @frsyuki

気合い入れてRagelで書くとか、そういう手段をあとで取るとして、現状は JSON extends MessagePack にして JSON では feed は UnsupportedOperationException を投げる案か、

Sadayuki Furuhashi @frsyuki

createBufferUnapckerメソッドなど実装が難しいAPIを含まない基底interfaceを作って、MessagePack implements ソレ + JSON implements ソレ にするか（JSONではByteArrayOutputStreamを使う）

Sadayuki Furuhashi @frsyuki

たぶん、後者のが良さそうな印象。それと関連してTemplateRegistryを誰が所有するか問題で…ありそうなケースは、JSONとMessagePackの両方を入力データとしてサポートしくて、@Messageクラスも同じという場合。TemplateRegistryを共有したい。

Sadayuki Furuhashi @frsyuki

一つの案は、TempalteRegistry tr = new TemplateRegistry(); MessagePack m = tr.createMessagePack(); とか。ちょぃと長い。使い勝手的に微妙感。綺麗だけど。

Sadayuki Furuhashi @frsyuki

そういう使い方をする人はadvancedな人なので、コンストラクタ MessagePack(TemplateRegistry); を用意しつつ、デフォルトでは MessagePack() { this(new TemplateRegistry(); } を呼んでね♪という案も。

Sadayuki Furuhashi @frsyuki

あるいは JSON(MessagePack m) { registry = m.registry; } とする案も。

Sadayuki Furuhashi @frsyuki

1クラス1機能主義に反した大クラスが出現すると、こういう問題が出てくるのかなー。register() が表に見えている時点で、TemplateRegistry 的な存在というか概念は理解してもらえるハズで、それを共有するにはこうするーという方法が明確なら何でも良いと思うのだけども

Sadayuki Furuhashi @frsyuki

JSONのデシリアライザは、unpackArrayBegin()が配列のサイズを返すことを要求する関係で、JSONUnpacker extends Converter になるはず。uArrayBegin()の方を変えるという案もあるけど、そこまでJSONに対応してもなぁと。

Sadayuki Furuhashi @frsyuki

最初の話は、StreamPacker/BufferPacker の分け方については、たぶん BufferPacker は StreamPacker+ByteArrayOutputStream の最適化版なので、BufferPacker extends StreamPacker

Sadayuki Furuhashi @frsyuki

が良くて、それなら名前は StreamPacker → Packer で良いと。関連して、Packer#close() を追加することになるハズ。BufferPacker#close() は何もしない。BufferPackerはPackerのAPIに加えて拡張APIを色々実装と。

Sadayuki Furuhashi @frsyuki

Unpacker側も同じ。BufferUnpacker#close() は何もしない。UnpackerのAPIに加えてwrapとfeedを持つと。JSONでfeedの実装が厳しい件はUnsupportedOperationExceptionを投げるのが良さそうな気がしてきたー

Sadayuki Furuhashi @frsyuki

Optional/NullableはOptionalに統一で…これはIDLも同じにする予定。optional修飾子が無くなって、?に統一かな。1: string? hoge とか。Templateをユーザーが直接使うことは無いと仮定すると、OptionalTemplateは不要。

Sadayuki Furuhashi @frsyuki

代わりにunpack(…, bool allownull)で。が、前バージョンの Templates.tMap みたいなのを追加するとなると、OptionalTemplateも欲しくなる。実は案外にコレが欲しい。genericsの型情報がローカル変数から取れればなぁ。

Sadayuki Furuhashi @frsyuki

これは後のバージョンで追加するか考える方針かな。

Sadayuki Furuhashi @frsyuki

あとTemplateBuilderで、フィールドに対するデフォルトの挙動をどうするか。publicフィールドだけシリアライズ対象というのは良い妥協点だと思っていて、自分で使っていて普通に便利。が、privateなのもシリアライズしたいのは非常に分かる。

Sadayuki Furuhashi @frsyuki

一つ考えている案は、register(Type) と registerBeans(Type) を作る案。JavaBeansに従ってもらう丸投げ。アノテーションも対応して @Message と @BeansMessage という感じ。

Sadayuki Furuhashi @frsyuki

デフォルトpublicフィールだけな方法と、JavaBeansで、どっちをデフォルトにするかは微妙。

Taro L. Saito @taroleo

@frsyuki Scalaもまたフィールドが違うので両方で使えるといいですね。

Sadayuki Furuhashi @frsyuki

あとはprivateなフィールドがあって、setterもgetterも無いクラスをシリアライズしたいというケースがあるハズ。これは register(Type, String[] fieldList) でどうでしょ？

Sadayuki Furuhashi @frsyuki

optionalの指定もしたい場合もあるので、最終的に register(Type, FiedEntry[] fieldList) に落ちる形でオーバーロードを色々。メソッド名要検討…

Sadayuki Furuhashi @frsyuki

yes! それもあるのです。RT @taroleo: @frsyuki Scalaもまたフィールドが違うので両方で使えるといいですね。

bickey81 @bickey81

「MessagePack使ったらTPS300%アップした」というキャッチフレーズは社内の人にもインパクトあったみたいだ。

Sadayuki Furuhashi @frsyuki

実はJRubyもあるという話は後にして、Scalaのフィールド一覧をFieldEntry[] に落とせれば何とかなりそうな予感。registerScalaClass とか…。これは 0.7.0 でも良い気がしてきました！