HTML コンパイラとしての Palmscape / Xiino

blog を習慣化するには何回かに分けて書くことができるネタを用意すればいいか、と考えた。

というわけで、 Palmscape / Xiino の実装について、特徴をまとめてみようと思う。

Palmscape のコーディングを始めたのは、たしか 1997 年 5 月。
当時最新の Palm デバイスは 16MHz の Dragonball に 1M のメモリを積んだ PalmPilot Pro 、これが唯一 TCP/IP スタックを積んだデバイスだった。

1MB のメモリといっても、そのうちワークメモリとして使えるのは僅か 10～20 KB。
残りは、読み込み only (書き込みは API 経由) のストレージメモリと TCP/IP スタックが使用する。この僅かなワークメモリで、どのように実用的なウェブブラウザを実装するか、というのが技術的課題だった。

(他製品のソースコードを読んだことがあるわけではないが) 一般的なウェブブラウザの実装は、 HTML から構文木を作成し、その木にレイアウト情報を付加していく、インタプリタ形式 (?) だと思う。

しかし Palm OS のワークメモリでは、 HTML を分割してレイアウト情報を負荷するだけの余裕がない。

必然的に Palmscape は、 HTML を逐次読み込みながら「カーソルを○○に移動して△△を書け」という中間コードへ変換し、ストレージメモリへ保存していく HTML コンパイラとして設計された。

この設計が、良くも悪くも Palmscape / Xiino の特徴となっている。良い点としては、

＋ ワークメモリより大きな HTML ファイルを表示できる
＋ ダウンロード終了後は中間コードを実行するだけなので、表示／スクロールが早い
＋ 余計なタグ情報を保存しないので、ダウンロード後のサイズが小さい

等が挙げられる。当時の HTML は単純であったことから、コンパイラ型という選択は正しかったと思う。しかし、今日の複雑化した HTML では、デメリットも少なくない。

たとえば、テーブル等２パスのレンダリングが必要な場合 (１パス目でテーブルのセルの幅を決定し、次にレンダリングを行う) は、メモリの節約にはならないし、ダウンロード時にレイアウトが固定化されてしまうので、 JavaScript を用いてオンデマンドに画像を差し替えるといったことは困難である。

また、ワークメモリも増加し、コンパイル型を選ぶメリットは小さくなった。

今、仮に、１からブラウザを作るとしたら、コンパイラとインタプリタの双方の特徴を併せ持ったハイブリッドとして実装するのがベストな選択なのではないだろうか。

次回は、画像サポートについて書いてみたいと思う。
＃その次は JavaScript?