![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
前置き†突然ですが拙作のJavaScript栞 MiyoJS が完成しました。みなさん使ってください！ という脈絡のない宣伝はさておき……。 上記MiyoJSは要は 「デスクトップアプリケーションのプラグインがJavaScriptでかける時代になっている」 ことを意味しています。 node.jsというサーバー用JavaScript実行環境が現れ、Windowsにも移植されたから可能になったことです。 新しい技術は次々と開発されています。 昔出来なかったことが今出来るようになっています。 本題†伺かで過去検討されたが結局実現していないこと……。 「Webゴースト」です。 昨今ブラウザ周り、HTML/JavaScriptまわりの事情は様々に進化しています。 サーバ向けJavaScriptが出たというだけでなく、ブラウザの中でも昔出来なかった様々なことが可能になろうとしています。 現在、Webゴースト、いやWeb独自仕様ではないmateria互換を取れるWebベースウェアが、以下の理由でついに実現可能と考えます。 Webベースウェアの基礎技術†栞まわり†プロトコル†栞はWindowsのDLLとして仕様策定されたため、プラットフォーム依存性が非常に強いものでした。 メモリ上でload, request, unloadを呼ぶ実装はJavaScriptベースウェアでもWindowsのAPIでない代替が必要です。 これについてはSHIOLINK.dllが定めたプロトコルを使うこととします。 拙作の栞で実用実績があり、合理的な仕様です。 既存の栞をこれに対応するには若干の修正が必要ですが、一番表層のIO部のことなのでそれほど込み入ったことにはならないと予想します。 またベースウェア側で使うSHIORIメッセージのビルダ等はすでに拙作ShioriJK等があるので解決済みといえます。 DLL†とはいっても、栞はそもそもDLLです。JavaScript栞はさておき、既存の栞はブラウザでは動きません。 しかしここにも光明があります。 C++のソース等をJavaScriptに変換できるEmscriptenというツールが存在します。 これはLLVMという次世代コンパイラ基盤によって可能になった技術です。 ソースが公開されている華和梨、里々、YAYA等はこれによってブラウザ上で動作する可能性があります。 とくに最大勢力のひとつであると目される里々はその複雑な仕様により、いちからJSで作るのはあまりにも大変だったでしょう。 その点これらにつぐゴースト数を持つであろう美坂等は、そう複雑な機能は持っておらず、JSで互換栞を書くことがコスト面で不可能ではないと思います。 これらをJS栞としてDLLを判定して組み込むことで、従来のゴーストの大半が動くという可能性が現実的になります。 このようにそこそこ作業量は予想されるものの、従来よりずっと現実的になったと思います。 ファイルシステム†栞は基本的にWebブラウザ環境を想定せずすべてローカルのファイルシステムのAPIを使おうとするでしょう。 これをラップして動作させるのは必須ですが、選択肢の一つにFileSystem APIがあります。 ローカルと同じようなファイルシステムをブラウザ上で実現してしまうHTML5の仕様のひとつです。 まだ対応ブラウザが少ないですが有望なひとつだと思います。 他にも逐一HTTP GETに変換してしまう、最初にメモリ上にロードしてしまう等もあります。 定められた場所にインデックスとして使えるupdates2.dauが存在するので、展開されてWebサーバ上に置かれたゴーストの全ファイルをロードするのは当然可能です。 またブラウザ上で動くZIP取り扱いライブラリJSZipも存在するので、narからの直接ロードや生成も出来ます。 narからのロードにより、「ゴーストの試用」をWebベースウェアを使って実現が出来るかもしれません。 シェルまわり†描画手法†これまではCSSやクリッカブルマップ等HTML4.01の仕様内で何とかする必要があり、煩雑でした。 現在は各ブラウザにSVGが普及したので、SVGで領域をとったり画像を動かしたりがプログラム的に自然に出来ます。 また旧来のブラウザに対しても使いたい場合も、Raphaël等を使えばサポートできます。 グラフ等もD3.js等を使うなどして描画できるので、使ってるぞグラフ、AIグラフ等のサポートも容易でしょう。 画像の扱い†画像はサーバー上に展開されている場合も、上記でnarから直接ロードする場合も、画像をメモリ上においておいて表示したほうが高速です。 これについても、Data URI schemeを利用することで、簡単にメモリ上の画像を表示することが出来ます。 結論†以上のように、もはやWebベースウェアを開発可能な環境は整っています。 実装工数がかかるところは各イベントの実装、さくらスクリプトとイベントの変換等いろいろあると思いますが、それは徒労に終わりません。 つまるところ……誰か作らない？ 補足†主に既存栞の扱いで問題になるのはIO部分です。 そこに拘泥するよりまずはIOの実装をシンプルに置換可能にしつつ、SHIORIの機能をそろえたJavaScript栞MiyoJSを栞サンプルとして、ある程度動作するWebベースウェアを作ってから既存栞に取り組むのが効率がいいと思います。 ……ステマじゃないよ？ ツッコミ等†おまちしています。 |
