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

2008年11月2日日曜日

Silverlight 2 for MobileはDLRをサポートしない?

SharpLab.さんの「Windows MobileとSilverlight 2絡みの話題について訂正・追補と落穂拾い」に、
Silverlight2 for MobileではIronPythonやIronRubyを動かすための基盤であるDLRがサポートされないとのこと。MSはSilverlight2が バラバラになるのを避けたいと考えているから、と説明されていますが、よくわかりません。
との記述があったので調べてみたのですが、Jimmy Schementi氏(MSのDLRチームのPM)の元記事へのコメント
Clarifying DLR support
By Jimmy Schementi Posted Friday 31st October 2008 23:44 GMT
Is correct that Silverlight for Mobile does not support the DLR today, since the Reflection.Emit namespace is not in the .NET Compact Framework. However, I'm making changes to the Silverlight integration for IronRuby and IronPython to let them run in interpreted-mode, which will not depend on Reflection.Emit. Once that happens then applications that run in interpreted mode can run on Silverlight Mobile. This will be in the next release on http://codeplex.com/sdlsdk.

と、Twitterでのつぶやき
@toddogasawara so it *should* work when/if the DLR interpreter doesn't depend on ref.emit

@toddogasawara cf doesn't have ref.emit, which the DLR compiler depends on. However, the DLR interpreter *could* run on it

を読んだ限りでは、
  • .NET Compact Frameworkには Reflection.Emit名前空間がないので、Silverlight for MobileではDLRのフルサポートはできない。
  • ただし、DLRでRefrection.Emitが必須なのはCompilerなので、Interpreterは依存しないようにする事もできる。
  • これについては、Silverlight Dynamic Languages SDKの次のリリース(0.5.0?)で対応するつもりだ。
という話のようです。ちょっと気になるのは、
  • Silverlight 2のCoreCLRは .NET FrameworkのCLRとは独立しているので、Silverlight 2の実行環境は .NET Frameworkのインストールを必要としないが、Silverlight 2 for Mobileは .NET Compact Frameworkのインストールを必要とするのか?
  • Compilerを使えるDLRと使えないDLRでアセンブリが変わるのか? シナリオとしては、
    1. Silverlight 2用のDLRとSilverlight 2 for Mobile用のDLRとして同一のアセンブリを利用できる
    2. DLRのCompilerが別のアセンブリに分離される
    3. Silverlight 2用のDLRとSilverlight 2 for Mobile用のDLRが別のバイナリになる
    の3択のはず。
の2点でしょうか。

.NET Frameworkは、DLL Hell問題を解決したのが長所らしいのですが、ExtensionAttribute Hellの件といい、今回の件といい、実行環境に依存した問題が続くとちょっと不安になりますね。

(追記 2008/11/03)
SharpLab.さんから、「Silverlight 2 for Mobileは .NET Compact Frameworkのインストールが必須要件のようです。」とのフォローがありました。
カメラ入力やスタンドアロンアプリケーションとしての実行等、将来のSilverlightで追加が予想されている機能をある意味先取りしているSilverlight 2 for Mobileが、独自のCoreCLRではなく、.NET Compact Framework CLRを採用するというのは、Silverlightの今後を予想する上で興味深いですし、採用を決定したのはSilverlight for Mobileのリリーススケジュールの遅延の原因なのか、結果なのか、それとも関係ないのか?という点でも考えさせられます。

2008年10月14日火曜日

【ネタ】Silverlight Assembly Server

Silverlight 2 アプリケーションを開発している時の悩みの一つとして、Silverlightのランタイムパッケージには含まれない拡張ライブラリ(実体は、*.DLLファイルで個々のファイルはアセンブリと呼ばれます)のサイズがかなり大きく、Silverlightアプリケーションの本体である、XAPファイルのサイズが大きくなってしまう事が挙げられます。

この問題は、実行時にDLRが必要なIronRubyやIronPythonを選択した場合に特に顕著で、C#で開発すればアセンブリの合計サイズが数KBで済むようなアプリケーションが、DLRと各言語用のランタイムライブラリで数百KB増加してしまいます。
現状のままでは、商用サイトのSilverlightアプリケーションではIronRubyやIronPythonは全く使われないだろうと考えられている原因の一つがこれです。(すみません、他の原因については今回は割愛します。)

このような状況を産んでしまった原因としては、まず第一に、Silverlightチームが、Silverlightのランタイムパッケージに含まれる基本ライブラリのサイズを極力減らして、ランタイムパッケージのインストーラのサイズを減らし、ユーザがSilverlightを導入する敷居を下げようとしている事が挙げられます。

DLRをSilverlightのランタイムパッケージに含めてくれれば……という声は、あちこちから挙がっているはずですが、DLRは1.0のリリース前でまだ安定していない事もあって、今のところその動きはないようです。

第二に、Silverlightには、.NET FrameworkのGAC(Global Assembly Cache)に相当する機能が無い事が挙げられます。
GACは、複数のアプリケーションで共有が可能なアセンブリをアプリケーションフォルダの外にインストールして、システムが一元的に管理する機能(らしい)ですが、Silverlightにこの機能が無いのは、Silverlightチームが、「Silverlightはデスクトップアプリケーションよりも信頼性が低いWebアプリケーションを対象にしている」という理由で、アセンブリの共有については、慎重な態度を取っているからではないかと考えられます。あとは、無制限にアセンブリを登録できてしまうと、Silverlight for Mobileのようなディスクの空き容量が少ない環境で困るというのも理由の一つなのかもしれません。

尚、GAC内のアセンブリが悪意を持ったアセンブリで改鼠されると大変な事になるので、これを防ぐためにアセンブリの署名という機能があります。
Silverlightのアセンブリのファイル構造は.NET Fremeworkのアセンブリのファイル構造と同じなので、Silverlightのアセンブリにも署名は可能です。実際、MS製のアセンブリには署名がついてます。

ただ、Silverlightには実行時にアセンブリの署名をチェックする機能自体はあるようなのですが、拡張ライブラリの署名済みのアセンブリと未署名のアセンブリで実行時の権限に差があるという話は聞いた事がありません。(この部分、自信ないです。私の勉強不足だったらすみません)
ひょっとすると、DRMを使っている間に限り、未署名のアセンブリを弾くような事をしているのではないか?と個人的に予想しているのですが、実際どうなってるのかは知りません。

閑話休題

余計な話が長くなりましたが、XAPファイルのサイズが増えると実際に困るのは、主に、

1.アプリケーションのロードに時間がかかる
2.XAPファイルを提供するWebサーバの転送量が増えてサーバの転送量の上限に引っかかる

の2点です。この内、2を何とかしようというのが、今回の、Silverlight Assembly Serverというアイデアです。
1については分離ストレージからアセンブリをロードするというアイデアを考えているのですが、これは別の機会に紹介します。

さて、Silverlight Assembly Serverとは要するに、

「誰かがcrossdomain.xmlがフルオープンのWebサーバを立てて、どこかのSilverlightアプリケーションが必要なアセンブリのリストを厳密名をつけて要求したら、それらのアセンブリが含まれるXAPファイルを返してくれるだけのサービスを作ればいいんじゃね?」

という話です。これだけです。

サービスの負荷については、XAPファイルが単なるZIPファイルである事を利用し、

・アセンブリはZIP圧縮した状態のバイナリデータを用意しておく
・XAPファイルに同梱するAppManifest.xamlファイルは要求に応じて内容が変化するがファイルサイズは大した事がないので、圧縮は「しない」

とする事で、最終的に、ZIPヘッダ、未圧縮のAppManifest.xaml、圧縮済みの個々のアセンブリを連結して返す「だけ」にしてしまえば、極力抑えられるのではないか?と考えています。

残る問題は、このサービスを提供するサーバが、サービスを利用するSilverlightアプリケーションが置いてあるサーバよりも回線が太く、安定していないとあまり意味がないという点ですが、これについては、

「Microsoftにはそういうサービスの提供を期待できそうにないけど、Google使えば余裕じゃね?」

という現実的な解決案がありますので、どなたか、ぜひ一度ご検討をよろしくお願い致します。m(__)m

2008年10月7日火曜日

PDC2008で発表されるSilverlightの最新動向の予想

2008年10月26日(日)~30日(木)、米国ロサンゼルスで Microsoft Professional Developers Conference 2008(長いので、PDC2008と略されます) という、Windows開発者向けのカンファレンスが開催されるそうです。

私は今まで自発的な興味は全く無かったので、どのようなイベントなのかはよく知らないのですが、きっとPDCというのはAppleのWWDCのようなお祭り騒ぎで、日本では有志が基調講演を同時通訳で実況しながらユーザー同士で檀上の発言にツッコミを入れるのを徹夜覚悟で待ちつつ、滅多に話せない人々とチャットで昔話に花を咲かせるような、それはそれは楽しいイベントなのでしょう……多分。

さて、PDC2008は、Microsoft社が現在開発中の最新技術を公開したり発表する場なのだそうで、当然、Silverlightの最新動向についても、一般向けの発表が色々あるはずです。私はSilverlightについては守秘義務契約に縛られるような内容は一切知らないという強み(?)があるので、時期的にまだ少し早いですが、PDC2008で発表されそうな内容を予想してみる事にしました。
以下、予想です。
  • Silverlight 2の正式リリース
  • 2008年の年末までにリリースされる、Silverlight 2の追加コンポーネント集
  • (Silverlight 3ではなく) Silverlight 2.1 の概要
  • DLR(Dynamic Language Runtime) に対応した VBx のパブリックベータ版の大まかなリリース日程
  • Silverlight 1.0 for Mobile の正式リリースと Silverlight 2 for Mobile のパブリックベータ版のリリース
  • PlayReadyによってSilverlightアプリケーション本体を保護した動画配信サービスが他社から提供
……あまり面白みの無い予想ですね、すみません。

2008年10月2日木曜日

雑記はじめました

雑記をはじめてみる事にしました。

Silverlight方面の話でTwitterの140字制限に収まらない話が増えてきたのですが、「連投うざいだろうなー」とか、「人様のblogのコメントで二十数行とか長すぎるよなー」とか悩んでるうちに、「こういう内容は雑記に書くべきだよね」という結論になりました。

どうして日記じゃないのか?はお察しください。