2008年12月13日土曜日

LHa for Native Client (本編)

【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。

(このエントリーは「LHa for Native Client (準備編)」の続きです。)

Native Clientの発表から、もうかなり経ちますので話題の旬はとっくに過ぎてしまったのですが、今回は実際にLHa for Native Clientを実行するところまで、何とか話を進めてみたいと思います。

ただし、LHa for Native Clientは、現時点でNative Clientがサポートしている3種類のOSの内、Mac OS XとLinuxで実行できることは確認しているのですが、Windowsでは今のところ実行に成功していません。

その理由を説明するには、そもそもNative Clientで何ができて、何ができないのか?を先に説明する必要があります。
当初はWindows版でも普通に動くだろうと思っていたので、これは誤算でした。

もう一つの誤算は、Native Clientが三日で飽きられてしまったためにx86ネイティブコードのsandbox以外の話を日本語で説明してくれるエントリに丸投げすることが出来なかったことです。
そのため、エントリがやたらと長くなってしまいましたが、どうか最後までおつきあいください。m(__)m

インブラウザモードとスタンダローンモード

Native Client上で動作する実行コード、これをGoogleはNatie Client moduleと呼んでいますので、以下では単にmoduleと呼ぶことにしますが、moduleには2種類の実行方法があります。

一つは、WebブラウザのNative Clientプラグイン上で実行する方法で、もう一つは、sel_ldrというローダを使うことで、単一のアプリケーションとして実行する方法です。

Googleは、この2種類の実行方法については、今のところ特に用語を命名してはいないようですので、ここでは仮にインブラウザモードとスタンダローンモードと呼ぶことにします。

moduleがスタンダローンモードとインブラウザモードの両方で実行可能な場合、moduleの実体である .nexeファイルは同じファイルで構いません。
基本的には同じ .nexeファイルが、Mac OS X、Linux、WindowsのどのOSでも動作します。

moduleの実行にはgccは不要

「GCCベースのコンパイラを含んだブラウザ用プラグインの形で提供され」と書いてある紹介記事を読んだために誤解している方がいらっしゃるようなので繰り返しますが、Native Clientは同一の.nexeファイルを複数のOSで実行可能なので、実行時にコンパイルは必要ありません。
Native Clientのパッケージに含まれているgccは、moduleのビルドに使われるだけです。

尚、moduleの実行環境及び開発環境そのもののビルドには、それぞれのOS向けの開発環境が別途必要になりますが、各OS向けのNative Clientパッケージはビルド済みの実行環境及び開発環境を含んでいますので、moduleをビルドして実行するだけであれば、実行環境や開発環境のビルドは不要になっています。

それから、Native Clientの実行条件として、Pythonが挙げられていますが、PythonはSconsというNative Clientの付属ツールや、スタンダローンモードのサンプルでsel_ldrを起動する際の補助に必要とされているだけで、Native Client moduleのビルドや実行に必須という訳ではないようです。

Native Client moduleの正体

正体という単語に期待した人には申し訳ないのですが、moduleの正体は、単に32-bit LSBなELF形式の実行ファイルです。

sandboxの実現のためにmoduleのビルドの際に実行コードに手を加えてはいますが、仕組み上、ELFのABIに違反するようなことはしていないはず(ここは自信なし、特にret)なので、moduleの実行をgdbで追いかけることもできるそうです。

しかし、Mac OS XのアプリケーションはMach-OというELFとは異なる形式で、付属のgdbもMach-O形式にしか対応していませんので、仮想OS上でLinuxを起動して、Linux上のgdbを使うのが無難だと思います。

それから、x86ネイティブコードのsandboxについては、id:amachangさんomoさんid:yaneuraoさんの各エントリに詳細が書いてありますので、そちらを参照することを強くオススメします。

Native Clientにできること

Native Clientは、newlibが提供する標準Cライブラリ、pthread、libSDLを使った音声と映像の出力機能の一部、NPAPIによるWebブラウザホストとの通信、IMCによるNative Client module同士の通信等が可能です。

スタンダローンモードではホストになるWebブラウザが無いためにNPAPIを使えませんが、実行時にAPIを呼び出した時点でエラーが返るだけなので、場合分けで処理を切り替えることも可能になっています。

スタンダローンモードで複数のmoduleを同時に実行してIMCで通信できるかどうかはちょっと分からないのですが、(私には難しそうですが)いつか試してみたいと思います。

映像出力と音声出力の仕様については、映像はRGBA各16ビットのフレームバッファになっています。フルスクリーンモードはありません。
「フレームバッファのハンドルはやるから好きにしろ、後は知らん」という感じですね。

音声は、44.1KHzまたは48KHzでステレオ、16ビットのリニアPCMを出力可能ですが、ヘッダのコメントによるとまだ多重再生はできないとのことなので、音声のMIXは自前で行う必要があります。

Native Clientにできないこと


Native Clientはまだバージョンが0.1ということもあって、使えるライブラリがほとんどありません。

GUIコンポーネントの表示どころか、基本的な描画ライブラリもなく、フォント、文字列エンコーディングの変換、画像、音声、動画のデコーダ等は全て自前で何とかする必要があります。

moduleは先に説明したようにELF形式なので、リンクできるライブラリもELF形式に限定され、Native Client向けにビルドしたライブラリである必要があります。
動的リンクはできないので、静的リンクのみです。

ですから、もしNative Clientで、例えばMac OS XのOpenGLライブラリを使用したいのであれば、実行環境をビルドする時にリンクして、moduleから利用するためのAPIを追加しなければいけません。しかし、それは実行環境の独自ビルドになるので、実行環境も一緒に配布しない限り、他の人のNative Client環境では実行できません。
結局、OpenGLやOpenCLについては、Googleが対応しない限りどうにもならないという事です。

Googleの今後の予定については何ともいえませんが、OpenGLやOpenCLを使えるようにするとセキュリティ上の安全性や安定性がOS側のドライバ頼みになってしまうので、見込みが薄いんじゃないかなーと個人的には思っています。あくまで個人的意見ですのであしからず。

ファイルI/Oの制限

ファイルI/Oについては、GoogleのTechnical Paperを読むと、ファイルI/OとしてPOSIX標準ファイルI/Oを利用可能だが、インブラウザモードの場合は、Web上のコンテンツの読み込みに用いられ、ファイル出力はできず、statはファイルサイズしか取れないと書いてあります。
これはHTTPではディレクトリ上のファイルの一覧を普通は取れないことを考えれば当然の仕様だと思います。

スタンダローンモードでもインブラウザモードの上記の制限を受けるために、クライアントPCのローカルファイルへのアクセスは基本的にできません。
(Native Clientがローカルファイルへのアクセスが自由に可能と説明している文章もあるようですが、それは何かの誤解だと思います。)

しかし、LHaはファイルの圧縮と圧縮を実行するツールなので、ローカルファイルにアクセスできないと意味がありません。

そこで、今回は、Native Clientに一つだけ用意されている抜け道を利用することにしました。スタンダローンモードのデバッグモードです。

デバッグモード

デバッグモードはsel_ldrに-dというオプションをつけて実行することで有効になるモードですが、このモードを使うとPOSIX標準ファイルI/Oでローカルファイルにアクセスすることが可能になります。

デバッグモードでもディレクトリエントリに対する操作はほとんど出来ませんが、ログ出力のために新規にファイルを作成したりバイナリファイルの読み書きを行う程度であれば何とかなります。

しかし、Windows版のNative Clientだけ、何故かsel_ldrでデバッグモードを有効にできません。
各OSで、スタンダローンモードでearthサンプルを実行してみた方は気づいたと思いますが、Windowsの場合だけフレーム数の表示がないことから、標準出力もできないようです。
これが、最初にWindowsでは動作しないと書いた理由です。

LHaの移植

今回のLHaの移植は、デバッグモードを利用しつつ、ディレクトリエントリが絡んだ部分を誤魔化す事で実現しています。

具体的には、Mac OS X上で普通に./configureを実行してconfig.hを作成した後で、nacl-gccでコンパイルした時にどのヘッダが足りないかを確認しながら、config.hの中身を適宜修正し、nacl-gccのリンカでエラーが出る関数をdummy.cというファイルででっちあげるという方法を取りました。

あくまで誤魔化しただけなので、ディレクトリ構造を持ったLZHファイルの作成や展開では問題が多々ありますし、実行権、シンボリックリンク、タイムスタンプ等も無視されます。最初に警告として実用には堪えないと書いたのはそのためです。

Makefileの流用も検討はしたのですが、結局、nacl_build.shというシェルスクリプトを用意しました。
結果的に出来上がったの以下のパッチとバイナリ

lha4nacl.patch
lha.nexe

lha4nacl.tar.gzというファイルにしておきました。

ビルド方法としては、Mac OS Xの場合、LHa for UNIXのソースを展開してから、上記のファイルも展開し、

$ patch -p1 <lha4nacl.patch
(nacl_build.sh 内のNACLINSTALLPATHを適宜修正)
$ ./nacl_build.sh

と実行すれば、src/lha.nexeが作成されるはずです。

lha4nacl.patchを読めば分かりますが、元のソースには一切手を加えていません。移植性を考慮したコンソールアプリのソースなら、機能制限に目をつぶれば元ソースに手を加えなくてもそこそこ動いてしまうのがNaClの面白いところだと思います。

以上、駆け足で説明しましたが、抜けているところは適宜修正していきたいと思います。
もし、何かありましたら、メールまたはKKI@Twitter等にご連絡ください。
おつきあいありがとうございました。m(__)m

【蛇足】"Native"な"Client module"

Native Clientの登場直後から、Native ClientはGoogleのOSになるのではないか?という意見を見かけますが、私はそうは思いませんでした。

というのは、GoogleがNative ClientのバイナリをNative Client Applicationではなく、Native Client moduleと一貫して呼称しているからです。

Native Clientのパッケージの階層は、nacl/google_client/nativeclient となっていますが、Native Client moduleは、"Native Client"の"module"ではなく、Google Clientの"Native"な"Client module"なのではないでしょうか?

つまり、Native Client moduleはあくまで、NativeではないClient moduleと共にGoogle Clientを構成するmoduleの一つであり、最終的には単体のアプリケーションとして動作させる利用方法は減っていくのではないか?ということです。

Google Clientがどのような物かはまだ分かりませんが 将来的には、例えばGoogle DocumentのエンジンがNative Client moduleになったりするのではないかと私は考えています。

LHa for Native Client (準備編)

【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。

GoogleのNative Clientのスタンダローン版のデバッグモードでLHa for UNIX (autoconf版)を動かしてみたのでメモ。

ウチの環境は、iMac(24-inch, Early 2008) 3.06GHzモデルなので、id:amachangさんの「ブラウザで X86 のマシン語を動かす! Google 謹製 Native Client をさっそく試してみる」を参考にさせて頂きました。記事と違う点としては、
  • nacl_mac_0.1_9380090.tgzがリリースされていたので、そちらを利用
  • wgetはMac OS Xには標準でインストールされていないので、代わりにcurlを使って、
    curl -O http://nativeclient.googlecode.com/files/nacl_mac_0.1_9380090.tgz
    を実行
  • ファイルの展開先は、~/src
  • サンプルのlifeは、
    $ cd ~/src/nacl/googleclient/native_client/tests/life
    $ ./run.py
    で実行
  • ./sconsは、~/src/nacl/googleclient/native_client/ から実行
  • ブラウザで開いたURLは、file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/earth.html
  • このURLで指定したファイルは、さっきまでの ~/src/nacl/googleclient/native_client/tests/earth ディレクトリのearth.htmlファイルではない事に注意。そちらのHTMLファイルを直接開くとearth.nexeファイルが同じディレクトリにないので、
    The Native Client plugin was unable to load
    というエラーが表示される。ここで少しハマった。
  • ブラウザ上でNative Clientモジュールを実行する時に、HTMLファイルをopenコマンドで開くと、file://localhost/... というURLになるが、この場合、
    Load failed: NaCl module did not come from a whitelisted source.
    Use a URL beginning with file://
    という警告ダイアログが表示され「(意訳)URLがfile://localhost/... になっているが、このURLは許可されていないので、file:///... にして開き直してくれ」と(何故か)怒られる。
  • testsディレクトリ以下にある、ブラウザで表示可能なサンプルのリストが(私の場合は)file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/index.html で表示されるので、こっちを使うのがオススメ
  • add.nexeとdiff.nexeは、testsディレクトリ以下にadd、diffディレクトリを作成してその中で作成したが、今回は .nexeファイルがあるので、同じディレクトリ内のHTMLファイルをブラウザで直接指定しても問題ない
等がありますが、これで id:amachangさんの記事の「文字列の diff を取る nexe を作ってみる」の項まで完了しました。

さて、ここからが本題である LHa for Native Client の話なのですが、Native Clientのバージョンが新しくなってしまったので、その確認等が終わってから次のエントリーで書く事にします。

2008年12月8日月曜日

MonoDevelop 2.0 AlphaのMac OS X版で日本語を表示する方法

Twitter@atsushienoさんから、@hayashihさんが、MonoDevelop 2.0 Alpha版のMac OS X版で日本語が化けて表示されて困っているという話を聞いたので調べてみたのですが、あまり良い方法ではない、というかむしろ最後の手段に近いのですが、

/Library/Frameworks/Mono.Framework/Version/Current/etc/pango/pango.aliases

というファイルを管理者権限で作成し、

"Lucida Grande" = "Hiragino Kaku Gothic Pro"

という行を書けば、とりあえず日本語が表示できることが分かりました。

結局のところ、初期状態のMonoDevelop.appで日本語が化けてしまう「根本的な」原因は、

Mac OS X版のMonoが依存しているPangoライブラリのpango-atsuiモジュールが、フォントファイルから表示可能なコードポイントの範囲を取得できないという理由で、全てのフォントファイルが全てのコードポイントのグリフを持っているという嘘の情報を作成し、Pangoがそれを信じてしまうので、フォントがフォールバックされないから。

ということになるのですが、この説明ではいくらなんでも不親切過ぎるので、まずは、Mac OS X版のMonoはどうやってフォントを表示しているのか?という話から始めたいと思います。

Monoは、GTK#, WinForms, libgdiplus, Cocoa#, Moonlight, etc... と様々な方法で文字をレンダリングできますが、今回問題になっているMonoDevelop.appの日本語は GTK# を使っているはずです。

GTK#は、簡単に言えば GTK+2 のラッパーで、基本的にはOSの違いの影響を受けないようになっています。
しかし、Monoが利用するGTK+2の実体は、OSによって様々です。

Mac OS X版の場合は、Monoの本体であり、/Library/Framework にインストールされる Mono.Framework内に、Imendio社Gtk+ on OSX というプロジェクトの成果(以下、gtk-osx)を同梱することで、.NETアプリケーションGTK#アプリケーションを、X11を起動せずに単独のMac OS Xアプリケーションとして起動し、GUIを表示する事ができます。

尚、gtk-osx は、環境変数を設定する事で、従来のようにX11アプリケーションとして動作させる事も可能のようなのですが、私はそっちはまだ試していません。

さて、GTK+2はテキストをレンダリングする際にPangoというライブラリを使う事になっていて、Mono.Frameworkのgtk-osxもPangoライブラリを自前で持っています。

Pangoがテキストをレンダリングする処理をもう少し具体的に説明すると、
  1. UTF-8で符号化された文字列とレイアウトに関する情報を受け取る
  2. 必要に応じて適切なレイアウトエンジンでレイアウトを決定し、バックエンドのフォントレンダリングシステムにグリフのレンダリングを指示する
  3. 返ってきた結果を元に、テキスト全体をレンダリングした最終的な結果を返す
という流れになります。

最近のPangoはバックエンドのフォントレンダリングシステムをCairo, Xft, FT2(FreeType2)の3種類から選択できます(core X font protocol は選択できなくなりました)が、Xftバックエンドと(何故かはよく知りませんが)FT2バックエンドはXサーバを必要とするので、「X11を使わずに」フォントをレンダリングするには、Cairoを使うしかありません。
ちなみに、Mono.Frameworkは、Cairoライブラリも自前で持っています。

CairoはCairoで、フォントのラスタライズをバックエンドに丸投げしてしまうのですが、こちらも選択が可能で、FreeType, Win32, Quartzの3種類があります。

FreeTypeは上記のとおりX11が必要ですし、Win32はWindowsのフォントラスタライザ、つまりGDIなのでMac OS Xでは当然使えませんから、結局「Mac OS X」で「X11を使わずに」フォントをラスタライズするには、Quartzフォントバックエンドを使うしかありません。Quartzは、Mac OS X 10.4から導入された、CoreTextフレームワークを使用します。

ここまでの話をまとめると、Mac OS X版のMonoでGTK#を使って多言語のテキストをレンダリングする場合の処理は、

MonoDevelop.app→Mono→GTK# → GTK+ 2(gtk-osx) → Pango → Cairo → CoreText

という流れになります。

上記の処理の中でテキストのレイアウトを決定するのは、先ほど述べたようにPangoです。

テキストを、単なる文字の並びではなくテキストとしてレイアウトするには、テキスト内の個々の文字のグリフの情報が必要になりますが、その際に得られる情報の内容は、同じフォントファイルから得られるグリフであっても、ラスタライザに依存します。

そのため、Pangoでフォント情報を管理する機能は、fontconfig, Win32, ATSUIの3種類のそれぞれに対応したモジュールに分かれています。
この中でATSUIを受け持つモジュールが、pango-atsuiモジュールです。

しかし、現在のpango-atsuiモジュールは、ATSUIで使用されるフォントが描画可能なコードポイントの範囲を正しく取得する事ができません。

何故かというと、ATSUIは元々単独で完結しているシステムなので、FreeTypeのようにフォントの詳細を得るためのAPIが存在しないからです。(この辺、ちょっと自信なし)

だからと言って、FreeTypeを使って個々のフォントファイルから直接情報を得ようとしても、ATSUIに対して指定したフォントの実体となるフォントファイルのパスを知ってるのはATSUIだけで、それを外から知る(真っ当な)手段がありません。ちなみに、この問題についてはWindowsのGDIでも似た状況らしく、吉里吉里の作者のW.Deeさんも苦労したそうです。

結局、pango-atsuiモジュールは、全フォントファイルが全てのコードポイントのグリフを持っているという嘘の情報をでっちあげるという方法をとってしまいました。

ですから、gtkrcやpango.aliasesでフォントのリストを与えて、描画できない文字をリストの次のフォントで描画(この仕組みをフォントのフォールバックと言います)させようとしても、Pangoがフォント情報の管理にpango-atsuiモジュールを使っている限り、リストの先頭で指定したフォントが全てのコードポイントの文字を描画可能ということになっているので、リストの先頭で指定したフォントを常に使い続けてしまうのです。

もう少し具体的な例で説明してみましょう。
Pangoに対して、Mac OS Xの欧文フォントである Lucida Grande で「あ」という文字を描画しろと指示した場合を考えてみます。
もしpango-atsuiモジュールが物理フォントで描画可能な文字の範囲を取得することができれば、PangoはLucida Grandeに「あ」という文字のグリフはない事が分かりますので、別の物理フォントにフォールバックすることができます。
しかし、Mono.Frameworkに含まれているPangoのpango-atsuiモジュールは、Lucida Grandeにも「あ」という文字のグリフがあるという嘘の情報を流し、Pangoはそれを信じてしまうために、フォールバックすることができません。

pango-atsuiが今回の問題の根本的な原因であることを納得していただけたでしょうか?

ちょっと長くなったので、この続きは次のエントリーに移して、
  • 以前のMonoDevelopでは有効だったgtcrcの書き換えが何故使えなくなったのか?
  • 現状のpango-atsuiの制限下で、Monoはどうすれば良かったのか?
の2点について考えてみたいと思います。

……えーと、多分、今週中には何とか(汗

(2008/12/08 07:15 追記) @atsushienoさんから、MonoのWinformsなアプリケーションはGTK+2に依存しないとの指摘があったので、.NETアプリケーションをGTK#アプリケーションに修正しました。

2008年12月4日木曜日

JavaFXって既にレガシーだよねwww

タイトルは釣りです。すみません。

さて、12月2日と3日に東京で「Sun Tech Days 2008 in Tokyo」というイベントがあり、Twitterの方で会場にいる参加者の方々の実況を見たりしていたのですが、Silverlightユーザの端くれでJavaはほとんど知らない私から見て、JavaFXアプレットについて、よく分からないところが3点程あったので、以下に挙げてみます。

その1
Silverlightには全画面モードがあります。
このモードには色々な制限があって、例えば、
  • 全画面モードへの移行にはイベントハンドラを使う必要があって、Silverlightアプリケーションの起動後に即全画面モードにはできない
  • 全画面モードは背景透過(Windowless)にはできない
  • 全画面モードに移行すると画面中央に警告が表示され、Escキーで全画面モードが解除できることと、Silverlightアプリケーションのホストのドメイン名が強制的に表示される
  • 全画面モードのキー入力には制限があって、通常の文字は入力できない
といった具合です。

これらの制限は、全画面モードでアプリケーションに好き勝手させると、本物そっくりの偽画面でユーザを騙してパスワードを盗むような悪質なアプリケーションが登場しかねないので、機能に制限を加える事で対策をしているというのが主な理由のようです。
これはSilverlightに限った話ではなく、AdobeのFlashの全画面モードにも同様の制限があります。

というか、むしろMicrosoftがFlashの全画面モードの制限仕様をパクったんじゃないの?なんて事は口が裂けても言いませんが、先月話題になったニコニコ動画の全画面モードにコメント欄が無い件も、上記の制限の影響を受けていたわけです。

ただ、AdobeはFlash10で全画面モードで使用可能なキーをいくつか増やしていて、これはどうやら、Silverlightの全画面モードでは使えるが、Flashの全画面モードでは使えなかった一部のキーを追加したようです。
AdobeとMicrooftがお互いの仕様を意識しつつ、セキュリティを考慮しながら利便性も高めようとしている様子が伺えます。

ここで質問ですが、JavaFXアプレットの全画面モードってどうなっているんでしょうか?

その2
SilverlightのUIコンポーネントは、全てベクターベースでスケーラブルになっています。
これは本来、GPUの支援下で高解像度で10フィートUIを実現するような場合に有利な方式のはずです。
例えば、1900x1200ピクセルの画面で、64x64ピクセルのグラデーションがかかったチェックボックスを描くような状況を考えてみます。
チェックボックスをピクセルベースの画像として持つ場合、少なくとも未選択状態と選択状態の2種類の画像が必要で実際には他にも画像が必要でしょうが、ベクターベースであれば、描画命令のリストで済みデータの量も少なくなるはずです。

しかし、MicrosoftはSilverlightをモバイル端末や車載端末のような低解像度のデバイスにも展開しようとしています。そのため、
「これだと、スケーラブルなUIの利点が活かしにくいと思うけど、どうなんだろう? もちろん、UIがスケーラブルだと拡大縮小のアニメーションが綺麗になるのは確かだけれど、そんなエフェクトのためにUIをスケーラブルにするのは、いくらRIAでもリッチ過ぎるんじゃないだろうか?」
等と考えていたのですが、最近になってHighDPIというキーワードを目にするようになって、
「あー、携帯端末の小さい画面でも将来的に解像度が縦横4倍くらいになったら、スケーラブルなUIの方が有利になるかもしれないし、Microsoftとしてはそれぐらい先を見越しておくべきだよね。AcrobatでPC画面上に紙を再現する事にこだわってるAdobeとしても、HighDPIは当然意識してるんだろうし、そういう研究開発もしてるんだろう。」
と考えを改めました。

ここで質問ですが、JavaFXアプレットのUIってベクターベースなんでしょうか?

その3
Silverlightには分離ストレージという機能があります。
分離ストレージを大雑把に説明すると、信頼できないアプリケーションがクライアント側でデータの永続記憶を必要とする場合に、ローカルストレージの代わりに提供される仮想的なファイルストレージということになります。
他の記憶手段、例えばCookieの場合、データの容量制限を別にしても、HTTPヘッダに常に全ての内容を載せる方式なので大量のデータには向きませんし、かといってWebサーバ側に永続記憶を持たせてしまうと、少なくともWebアプリケーションの起動時にクライアントにデータを転送し、終了前にクライアントが変更したデータをサーバ側に転送する必要があります。
データへの操作が、「画像のこの範囲にグラデーションをかける」のような単純なコマンドでで済む内はいいですが、大量のデータを全面的に修正するような状況、例えば何かの映像にクライアント側のローカルストレージ内の任意の画像を重ね合わせて表示するような話になると、さすがに無理が出てきます。

分離ストレージはクライアント側の永続記憶で、Cookieのように毎回Webサーバに内容を送るような事はしないので、上記のような用途には特に向いています。(Webアプリケーションで映像を編集するのが現実的かどうかは別にしてですが)

それから、分離ストレージは通常はアプリケーション別に管理され、ローカルストレージとは独立していますので、ローカルストレージへのアクセス権限がなくても利用できますし、他のアプリケーションからデータを保護する事もできます。容量については初期状態で1MBの容量制限があり、拡張が必要な場合にはユーザにダイアログで問い合わせる仕組みになっています。

Flashの方にはSharedObjectという機能があって、これが分離ストレージと大体同じ機能のようです。
今時、Webアプリケーションに、「PC内の貴方のデータ全てを好きにいじる許可を頂けますか? OK/Cancel」とか言われても困ってしまいますよね?

ここで質問ですが、JavaFXアプレットはこの辺の仕組みはどうなっているんでしょうか?



上記の3点、かなり気になってますので、詳細をご存じの方がいらっしゃいましたら、どうか教えてください。よろしくお願いします。m(__)m