【ネタ】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ファイルのサイズが増えると実際に困るのは、主に、

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

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

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

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

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

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

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

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

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

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

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