私たちは、Monoプロジェクトとその新しい親会社であるXamarinの創設者であるMiguel de Icaza氏と話すことができた。いくつかのトピックで、Mono上のASP.NET MVCの将来とMoonlightプロジェクトの終了についてもカバーしている。
InfoQ: Monoは早い段階からASP.NETをサポートしていました。あなたはこれをただのチェックボックス機能と見ているのですか、それともMonoプラットフォーム上のASP.NETに多大な興味があるのですか？
Miguel de Icaza: 私たちはしばらくの間、アンケートを採っていませんが、最後のアンケートでは多くの人がUnix上でASP.NETを実行させることに興味を持っていました。MicrosoftがWindows Serverのライセンスを修正したとき、興味が減少したため、これらのケースにおけるMonoの金銭的な魅力は減少しています。今日の主軸は、他のほとんどをLinux中心にしたときにASP.NETを実行することです。
InfoQ: ASP.NET MVCはオープンソースになりました。以前は、Monoで互換性を持たせるためにどのぐらい大変でしたか？
Miguel: MVC 1とMVC 2をMono上で実行することは非常に簡単でした。MVC3は違っていて、MVC3はオープンソースになりましたが、その時にはオープンソースになっていないライブラリや古くからあるライブラリに依存していました。そのため、MVC3をサポートすることは簡単でしたが、デプロイは面倒でした。あまりに面倒なので、MonoでMVC3を配置していることはまれでした。
最近Microsoft ASP.NETライブラリは開示されるようになったので、私たちはMono上でMVC3がすぐに動作するように管理しています。
最後にMVC4は、しばらくの間動作させることができません。MVC4は、コアASP.NETで新しいasyncパイプラインをサポートする必要がありますが、現時点でこの作業をしている人はいません。これは、Monoにこの変更を加えることに興味がある人たちがいるかどうかの問題になります。
InfoQ: あなたは互換性を維持するために、直接ASP.NET MVCに貢献していますか？
ASP.NET MVCのオープンソース化の主な利点は自分達のコミュニティのためです:長期的な技術革新、エクステンションのバグフィックスはMicrosoftの開発者が行ったものに限定するか、それをできるか、または指定することができます。これによりASP.NETは、他のオープンソースフレームワークにならって、急速に成長し、迅速に対応していくでしょう。
InfoQ: 現在、4つの異なるXAMLベースのUI技術が存在しています: WPF、Silverlight、Silverlight for Windows Embedded、Silverlight for Windows Phone。Windows 8の登場で、5つめのバージョンが登場したと考えていますか？この多様化になにか意見はありますか？
Miguel: 私たちは現在、C# for Android、iOS、Macにフォーカスしており、XAMLベースのフレームワークの影響は受けていません。
XAMLに興味深い面がありますが、私はマークアップのためにXMLを完全には買っていません。私は長い間、JsonのマークアップやJavaFXの一部のマークアップのように、人が書くことができるシンプルなものを採用することを望んでいました。それは、ツールからの利用とメンテナンスが容易ですが、プログラマが読むのも容易で、タイプもしやすいです。
ある時点で、私たちはSilverlight 3/4マークアップを描画できるオープンソース描画エンジンを実装しました。
そのとき、私たちは開発者にアプリケーションを2つに分割するように指示しました:ひとつはすべての.NET/Monoプラットフォームから使用できる再利用可能レイヤ、もうひとつはプレゼンテーションレイヤの実装です。iOS、Android、Mac、WindowsのネイティブUIかそのHTMLバージョンのいずれかです。
InfoQ: 多くの開発者がプラットフォームをまたいだUIコードを標準化するPhoneGapのようなプラットフォームに切り替えています。あなたは、C#で使えるiOS、Android、Windows PhoneをまたいだUIライブラリを見たことがありますが？
Miguel: これらの混合が存在しています。
短く、限られた予算にあるとき、プレゼンテーション層はwrite-once-run-anywhereで使いたいでしょう。これは、Javaで一般的になったが、私たちはGtk#とXwtライブラリを使った私たちのツールでこれを使っています。
あなたが最善のユーザーインターフェイスを提供したい場合、カスタムのネイティブコードを書く必要があるときがあります。このような場合にも、現在、それぞれのプラットフォームのネイティブであるMono用の新しいドキュメント作成システムなど私たちのツールを使うことができます。
特にMacとiOSの世界では、最終的な品質とネイティブUIで高い価値を提供することができなかったため、クロスプラットフォームUIは実際には最高のエクスペリエンスをユーザーに提供できていません。
InfoQ: Novellが買収される前、何人かがAndroidタブレット上で実行するMoonlightの開発をしていました。これはまだ継続中ですか？
Miguel: 私たちはMoonlightを破棄しました。
InfoQ: Moonlightは非常に有望だと見ていたので残念です。人手が足りなかったのですか？それとも将来的にもブラウザベースのSilverlight/Moonlightはもうないのですか？
SilverlightはWebでそれほど採用されていないので、今後持っている必要がある技術ではありません。
またMicrosoftは、デスクトッププログラミングのために役に立たない制限をSilverlightに追加しました。
私たちは今後、Silverlightがwrite-once-run-anywhereのプラットフォームでありつづけるとは考えていません。それを有用にするためには制限が多すぎます。C#の世界での最適な選択は、コードをプレゼンテーション層で分割することだと考えています。 ユーザーは彼らのアプリケーションのコア部分を、全てのプラットフォームで再利用して、新しいUIコードを対象にしているそれぞれのプラットフォーム用に書くのがよいでしょう:iOS用にはMonoTouch、Android用にはMonoDroid、Mac用にはMonoMac、Windows・Mac用にはWPFかWinforms、WebにはASP.NET、そしてWindowsとLinuxにはGtk
これはwrite-once-run-everywhereとは言えませんが、結果的にアプリケーションはネイティブの世界で動作して、それぞれのプラットフォームのネイティブなエクスペリエンスを実現することができます。
InfoQ: もしMonoのオープンソース部品を開発するボランティアが増えたとしたら、どのエリアに作業を割り当てたいですか？
Miguel: 今後リリースされるWCFの4.5 APIに当てたいです。
Microsoftはこの.NETのAPIで多くの更新をしてC# 5のasyncにも対応しました。 私たちがベースクラスライブラリの作業を終えたら、個人的にはSystem.Data (と、私たちのSqliteのような継承クラス)のAsync対応と、開発者が活用することができるasyncパイプラインも動作するASP.NETスタックもAsync対応したいです。
Microsoftが先日オープンソース化したASP.NETのすべてのコードを活用するためには、ASP.NETの改良が必要です。これらの変更なしでは、Monoは新しいオープンソースコードの半分が実行できないか、再利用に制限がかかることになります。
InfoQ: おそらくAndroid APIにおけるOracle/Googleの訴訟について興味があると思います。この状況をどう見ていますか？
Miguel: これはまるで戦争のようで、最初の攻撃のあと、誰もが無実でなく、誰もよくは見えません。これは両社とも評判を悪くしています。
InfoQ: これに関連して、もしAPIに著作物が見つかった場合、MicrosoftはMonoプロジェクトを脅かすと思いますか？
そうは思いません。
Google/Oracleの議論は、数十億ドルの闘いに有用な高レベルAPIがなく、コアAPIを超えています。GoogleはAndroidの要素として異なるAPIセットが必要だったので、基本的に高レベルのビッツを採用していません。Mono/.NETの世界では、コアAPIの配布に必要な著作権はECMA/ISOに与えられており、高レベルAPIは数十億産業のための怪しい使用のままになっています。もし数十億ドルのビジネスが.NET/Monoの周りに現れた場合、私たちがMonoTouchとMonoDroidで行ったように高レベルのものを取り除き、コアを使用するようにします: 私たちはコアを使用していますが、ネイティブのAppleやAndroid APIを置き換える代わりに、高レベルのWindowsのAPIを公開することはありません。