メモ

MessagePackの機能強化

C APIC++ APIにあるような動的型付けオブジェクトをサポートする。コールバック関数を登録するタイプのストリーミングデシリアライザは使いにくい上に遅い(関数呼び出しが多い)ので、今後置き換えていく方針。C APIの動的型付けオブジェクトはC++ APIの動的型付けオブジェクトと相互にキャストできる。
メモリプールの実装は大幅に高速化している。C++のメモリプールの実装は元からシングルスレッド前提だが、その割には無駄にmalloc()していた。これをまとめてmalloc()することで大幅に高速化。
C++デシリアライザはゼロ・コピー化される。参照カウンタ方式でバッファを共有する。今までと使い方はまったく同じだが、メモリプールの機能が強化されているので、そのAPIを使う。
ActionScript版、Java版、Lua版。

Webアプリケーションにおける非同期通信

Ajaxはpull型。そうではなくてCometやAerialを使ったpush型について。クライアントにとりあえず「ちょっと待ってね」とか「読み込み中」のようなレスポンスを返しておき、サーバー側で準備が整ったときにクライアントにpushする(ようにプログラムを書くことができる。実際にはpull=Comet/Ajaxかもしれないが、そこを抽象化する)。


Webアプリケーションから見ると非同期サーバーは、単なるkey-valueストレージに見える。しかしここにkeyを保存すると、そのデータがクライアント(ブラウザ)にpushされる。Webアプリケーションはとりあえずクライアントにkeyを返しておき、クライアントにはそのkeyについてlong-polling(とかAerialで接続)しておいてもらう。Webアプリケーションは準備が整ったら、そのkeyにデータをsetしてやればいい。
単なるkey-valueストレージに見えれば十分なので、非同期サーバーにはmemcachedプロトコルを実装する。


典型的には以下のようなストーリーになりそう:

  • Webアプリ:クライアントから何か重いリクエストを受け取る
  • Webアプリ:UUIDなどを使って一意なkeyを生成する
  • Webアプリ:クライアントに「ちょっと待ってね」と返す。このときkeyも渡しておく。
  • Webアプリ:ジョブサーバーにkeyと処理を突っ込む
  • クライアント:「ちょっと待ってね」を表示して、CometやAerialなどを使ってkeyをサーバーにリクエストする
  • 非同期サーバー:既にkeyが保存されていればそれを返す。保存されていなければLong-pollingしたままクライアントを待たせる
  • Webアプリ(ジョブサーバー):処理が完了したら、非同期サーバーにkey=>valueを保存する
  • 非同期サーバー:クライアントに結果を返す

WikiForme案

WikiFormeは機能が肥大化していて機能を加えるとかプラグイン書くとかが面倒になっているのが問題。
そこでWikiForme自体は「Wiki記法の文章をパースして木構造に組み立てて、XMLを生成する」という機能だけに絞り、そこからPDFやHTMLを生成する機能は別のプログラムに分ける。

XMLは本来ドキュメント用のフォーマットなので、こういう用途にこそ適しているのではないか。
XMLに限定することで、「上の要素に属性を追加する」というようなプラグインを一般的に作れる。現状では追加される側に変更が必要なので使いにくい。

Partty!.org案

システム全体をパッケージ化して、Partty!サーバーをいろんなところにインストールできるようにしたい。
現状ではサーバーはRubyで実装してあるが、これがイケてない。少なくともEventMachine/Rubyをアップデートすると動かなくなること必至。
そこでJavaで書き直したいと思う(C/C++はキツイがRubyもどうよ → Python, perl…うーん、Javaかな)


それからクライアントに実装がヘタレな感があるので書き直したい。これはCで。プロトコルは変えないようにしておく。
FlashのターミナルエミュレータはUIがイケてない。背景色を変える機能があるのだけど、変えるためのUIが無いので使えない。スクロールしないと下の方が見えない。再生が終了した後でもシークバーが使えるようにしたい。

分散ストリーム解析

MessagePackでシリアライズされたストリームを簡単に分散処理する。何日も掛けて解析するような規模ではなく、半日を1時間にするとか、そういう規模で。
分散処理のプロセスは、以下の3つに分ける:

  • init:初期化
  • run:分散処理本体
  • view:後処理、結果の表示

initでTokyo Tyrantを初期化する。runでデータを読み取って次々に処理してTokyo Tyrantにデータを保存していく。viewで保存されたデータを元に結果を表示する。
ここで、init、run、viewを多段にすることで様々な機能を実装できる:

  • init
    • init
    • run
    • view
  • run
  • view
    • init
    • run
    • view

途中の計算結果を1つのTokyo Tyrantに保存していくところがポイント。Tokyo Tyrantの性能に律速されるのではと思われるかも知れないが、最近のkey-valueストレージの盛り上がりを見るに、何らかスケールアウトする実装が出てくるに違いない。
init, run, viewはLuaで記述できないか。分散ランタイムはCやC++で実装する。あるいは全部Javaとか、分散ランタイムはJavaでinit, run, viewはJavaFX ScriptとかJRubyとか。