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月14日火曜日
2008年10月7日火曜日
PDC2008で発表されるSilverlightの最新動向の予想
2008年10月26日(日)~30日(木)、米国ロサンゼルスで Microsoft Professional Developers Conference 2008(長いので、PDC2008と略されます) という、Windows開発者向けのカンファレンスが開催されるそうです。
私は今まで自発的な興味は全く無かったので、どのようなイベントなのかはよく知らないのですが、きっとPDCというのはAppleのWWDCのようなお祭り騒ぎで、日本では有志が基調講演を同時通訳で実況しながらユーザー同士で檀上の発言にツッコミを入れるのを徹夜覚悟で待ちつつ、滅多に話せない人々とチャットで昔話に花を咲かせるような、それはそれは楽しいイベントなのでしょう……多分。
さて、PDC2008は、Microsoft社が現在開発中の最新技術を公開したり発表する場なのだそうで、当然、Silverlightの最新動向についても、一般向けの発表が色々あるはずです。私はSilverlightについては守秘義務契約に縛られるような内容は一切知らないという強み(?)があるので、時期的にまだ少し早いですが、PDC2008で発表されそうな内容を予想してみる事にしました。
以下、予想です。
私は今まで自発的な興味は全く無かったので、どのようなイベントなのかはよく知らないのですが、きっと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アプリケーション本体を保護した動画配信サービスが他社から提供
ラベル:
Silverlight
2008年10月2日木曜日
登録:
投稿 (Atom)