自己組織化するアプリケーションの話しはまだ続きますが、一区切りつきましたので、宿題になっていた、以前のエントリー「jigブラウザの可能性−ケータイ用フルブラウザ機能のASPサービスへ」に対するH.O.さんのコメント、
一通り読ませていただきましたが、サーバ側で動作しているブラウザをケータイブラウザでエミュレーションするのは（少なくとも現状では）不可能でしょう。
それを行うには、キー操作一回する毎に毎回サーバにアクセスする必要があります。
ケータイブラウザからのアクセスはHTTPを使うほか無く(BREWであればソケット通信が出来ますが、BREWでフルブラウザがKDDI以外から提供される可能性は低いでしょう)、これは毎回接続を行わなくてはいけないことになります。
に対する回答を書いておきます。
ケータイブラウザのエミュレーション機能の一番重要な部分が、この昇り方向のキー操作のエミュレーションです。もちろん、H.O.さんが書いているような「キー操作一回する毎に毎回サーバにアクセスする」つもりはありません。
方法は簡単です。ASPサーバー側のEMプラグインで、フルブラウザによる表示画面の入力フィールドをすべてチェックすればいいのです。この情報をケータイブラウザに渡すことで、ケータイブラウザは通常画面のエミュレーションと併せて、渡された情報から生成したリッチテキストベースの入力を組み合わせて表示します。リッチテキストベースの入力ですから、昇りはキー操作一回ごとではなくなり、通常のケータイアプリと同程度の通信で済むようになると言うことです。
実はこれは昇りだけでなく降りでも使える技術です。現状のjigブラウザによる情報圧縮と同じロジックを使うことで、ASPサーバー上のフルブラウザ画面のエミュレーションと圧縮した情報と組み合わせて表示することも可能になります。
これらが実現できるのは、エミュレーションと言ってもサーバー上の全てのアプリケーションのエミュレーションではなく、ブラウザ画面のエミュレーションと言う特殊機能だからです。
話は変わりますが、以前から社外でメールのチェックをするのに、エアエッジで通信できるB5ノートにインストールしたメーラーから直接メールサーバーにアクセスしていましたが、最近メーラーをASPサービスでブラウザから利用できるように変えました。
これがメチャクチャ便利になって、以前の、通信状況を気にしながら何百通あるメールを落としていたのと比べると天国です。何が便利になったか。
■画面をエミュレーションしているだけなので、メールのダウンロード時間がサーバー間の通信速度で行われる。
■自宅でも、別のパソコンのメーラーでダウンロードしていたため、何度も同じ内容のメールをダウンロードすることになるが、ASPでは自宅のパソコンも関係なく同じメーラーを使用できるので、ノートで読んでいたものの続きからチェックできる。
この調子で、会社のパソコンにあるアプリをどんどんASP化していけば、どこでも仕事ができて、とっても嬉しい（大変！）。 KAI
H.O.
本文でのご回答ありがとうございます。
読ませていただきましたが、現状の携帯電話上ではこのシステムの実現は無意味でしょう。
この方法では、例えばJavaScriptのイベント処理（マウスカーソルが乗っている間だけ画像変更…など)はどのように実行されるのでしょうか？
一つの方法としては、イベントが発生した結果の画面を全て送るという方法ですが、データが膨大になるため、送受信に時間が掛かる上に携帯上のメモリが足りなくなるでしょう。
そもそも発生するイベントを全てスキャンするなんてことをやっていたら、サーバのスペックがいくらあっても追いつきません。
2つ目の方法はイベントが発生するたびにサーバにアクセスする方法ですが、これは本末転倒でしょう。結局通信時に時間がかかり、快適に利用できなくなります。
3つ目の方法が「諦める」です。これはjigブラウザが取っている方法ですね。
ですが、画像が変わる程度ならともかく、イベントでリンクの表示非表示を切り替えるようなJavaScriptのあるサイトでは、JavaScriptの使用を諦めるということは、すなわちそのサイト自体の閲覧を諦めることになります。わざわざASPサーバ上のブラウザをエミュレートする意味があるでしょうか？
ということで、この方法ではFlashやappletはおろか、JavaScriptにすら対応できません。さらに、入力に対してブラウザが独自に処理を行うのであれば、端末の能力や機能に依存します。つまり、「jigブラウザの可能性−ケータイ用フルブラウザ機能のASPサービスへ」で挙げられていた…
・ケータイ機種が変わっても全く影響を受けない
・各種ウェブアプリの実行の制限を受けにくい
・クライアントのディスク容量制限を受けにくい
等々
というようなメリットは全く働かなくなってしまいます。そんなシステムをわざわざ作る意味はあるでしょうか？
KAI
コメントありがとうございます。
この仕掛けのポイントは、本文にも書きましたが、特定のフルブラウザのみのエミュレーション機能ですから、もともとブラウザ自体のEMプラグインでレンダリング情報を入手していることです。ですから通常のエミュレーションとは考え方も手法も異なります。
ご指摘の「JavaScriptのイベント処理（マウスカーソルが乗っている間だけ画像変更…など)」は、スクリプトに記述されている範囲でケータイブラウザで処理してしまいます。確かにスクリプトに出てこないAPIによるイベントにどう対応するかありますが、特定のフルブラウザ（特にOSSの)を対象にするというのもこの辺りに対応できるようにすると言うことも考えてのことです。
まあ、実際にこれをやるには、jigブラウザでご苦労されているのと同じぐらい簡単ではないでしょうが、ASP化するメリットの方が大きいと考えます。