PIGSの Ver 0.3.0の基礎部分が出来てきました。

18ヶ月掛けた実装をぶっ壊し、再設計からやり直した Ver 0.3.0が動き始めてきました。

18ヶ月もの長丁場で実装しているせいもあるんですが、
最初は気が付かなかった機能とか仕様とか、ポッっと沸いたアイデアを途中から盛り込みたくなるのが私の悪い癖です。

そのたびになんども設計の見直しが入ちゃっていましたので、
一部はバベルの塔のようになりかけていた感がありますが、
今回の組みなおしでなんとか、形になってきました。

現在は、環境設定ウィザードとインストーラーのリライトが終わり、
コアの機能も50%ほど復旧しています。

mod_wysiwyg や mod_googlemap などのキャッチーなモジュールから
再実装を進めて行き、来月中旬ぐらいには、機能縮小版をリリースしたいところです。

肝心のWebページの生成速度は、
モジュールのオンデマンドロード等の根本的な実装変更の成果と、
読み込むファイルの数を 44個 ⇒ 12個と大幅に減らしたことにより、
0.173秒 ⇒ 0.064秒 と約2～3倍の高速化となりました。

その他にもいくつか機能を追加してあるので、
幻の Ver 0.2.0 よりは、ユーザのニーズに沿ったWebアプリになりそうです。

素材やデータの共有

PIGSのユーザ同士でデータを共有する仕組みを小一時間ほど考えています。

現段階で考えているのは、素材(画像)やカバーデータなどの共有についてです。

データを共有するためには、ユニーク性を確保するために、

・Webサイト毎にサイトIDを割り当て、
・データの種類(kind)を定義し、
・データ毎に個別のIDを割り当てる。

といった、ネットワークでユニークな共有データIDを与える作業が必要になりますが、
あまり各桁数を欲張って多く取りすぎると、int32の範囲を超えてしまいそうです。
# floatは無駄に性能が劣化しますし。

今のところは、共有データIDのフォーマットは、0xSSSSKDDD の形で、

(S) サイトIDは、0x0001～0x7fff で 32766サイトまで。
(K) データの種類は、0x0～0xf で 15種類
(D) データIDは、0x001～0x0fff で 通常4094個
※ Kの下位1ビットを間借りした場合は最大で8189個

としようかと。

Kの使い道は、とりあえずこんな感じで。

0x0: 画像セット 0000 + 0xffff
0x1: 画像セット 0001 + 0xffff
0x2: 素材データ 0010 + 0xffff
0x3: (予約) 0011 + 0xffff
0x4: コンテンツ 0100 + 0xffff
0x5: (予約) 0101 + 0xffff
0x6: 背景 0110 + 0xffff
0x7: カバー 0111 + 0xffff
0x8: モジュール 1000 + 0xffff
0x9: Webページ 1001 + 0xffff
0xA: レイアウト 1010 + 0xffff
0xB: テーマ 1011 + 0xffff
0xC: サンプルWebサイト 1100 + 0xffff
0xD: (予約) 1101 + 0xffff
0xE: (予約) 1110 + 0xffff
0xF: (予約) 1111 + 0xffff


問題はこれを、開発中のVer 0.2.0に組み込むかどうかなんですが、
互換性がなくなるのは確実なので、できれば早めに着手しておきたいところです。

ただでさえ、毎日のように修正個所が見つかるので、
リリースに適当なタイミングが見つからずにリリースできないでいるのですが、

Ver0.2.0のリリースはまたまた遅れるのか…
手が二本では全然足りませんなぁ…

Ajaxでチャタリング

PIGS in Ajaxなお話。

誰がオンライン中なのかを表示するモジュール(mod_whos_online)というのを再開発しているんですが、
オンライン状態を正確に把握するための仕掛けとして、Ajaxでkeep alive(ping)しています。

・PIGSが、Webページ作成時に在席状態を示すフラグをONにセットします
・ブラウザクローズまたは、他のWebページに移動する際にonunloadイベントを発生させ、Ajax経由で、在席状態を示すフラグをOFFにセットします。
・ブラウザ上で、一定間隔でイベントを発生させ、在席状態をPIGSに通知し、最終更新日を記録します。
・最終更新日を元に、ガベージコレクション処理を走らせ、既に居ないユーザ(フラグがOFF)の情報を削除します。

と、ここまで書けば、まぁ普通に動作しそうなんですが、
問題は、JavaScriptの動作が遅いため、onunload 処理が後から飛んでくるので、
ページリロード時に、フラグをONにセットしても、直後にOFFに上書きされてしまうという現象「チャタリング」が発生することです。

「トラ技」的には、コンデンサでも噛ませて、信号のぶれを吸収すればいいんですが、いかんせん相手はプログラムですし、非同期通信なので、そーもいかず。

結局、3秒以内にフラグの更新(ON ⇔ OFF)が連続したときは、チャタリングが発生したとみなし、更新しない処理をSQL文で実装し、まぁなんとかうごくようになりました。

3秒に根拠がないので、微妙です。