Nous avons eu l'occasion de discuter avec Miguel de Icaza, fondateur du projet Mono et de sa nouvelle société parente, Xamarin. Nous avons abordé entre autre l'avenir de ASP.NET MVC sur Mono et la fin du projet Moonlight.
InfoQ : Mono a supporté l'ASP.NET depuis les premiers jours. Voyez-vous cela comme une simple fonctionnalité qu'il faut proposer ou y a-t-il beaucoup d'intérêt dans la version ASP.NET de la plate-forme Mono ?
Miguel de Icaza : Nous n'avons pas fait de sondage depuis un moment, mais dans le dernier que nous avions fait, ASP.NET sur Unix était encore une fonctionnalité imortante pour les utilisateurs. Je dirais que l'intérêt pour cette version a diminué lorsque Microsoft a corrigé le souci avec les licences pour les serveurs Windows, car l'attrait financier de Mono a été réduit. Aujourd'hui, le principal intérêt est de pouvoir exécuter du code ASP.NET lorsque le reste des couches logiciels est centrées autour de Linux.
InfoQ : ASP.NET MVC est open source depuis un moment. Dans le passé, à quel point cela a été compliqué de le rendre compatible avec Mono ?
Miguel : Faire fonctionner MVC 1 et MVC 2 avec Mono a été très facile. Avec MVC3 les choses ont changé puisque MVC3 était open source mais embarquait certaines dépendances sur des librairies qui n'étaient pas open source à l'époque, ou étaient des librairies temporaires. Donc supporter MVC3 était facile, mais le déployer non. C'était très rare de voir un site MVC3 déployé avec Mono car c'était tout simplement trop difficile.
Avec l'ouverture récente des librairies Microsoft ASP.NET cela a changé, et nous avons réussi à faire fonctionner MVC3 sans modification avec Mono.
Enfin, pour MVC4, nous ne serons pas en mesure de le supporter prochainement, puisque MVC4 nous oblige à mettre à jour le moteur de base ASP.NET pour supporter le nouveau pipeline asynchrone et actuellement personne ne travaille là-dessus. Cela dépendra si des gens s'en soucient suffisamment pour contribuer et faire fonctionner ces changements Mono.
InfoQ : Voyez-vous la possibilité de contribuer directement à ASP.NET MVC comme un avantage important pour maintenir la compatibilité ?
Miguel : Le principal bénéfice apporté par l'ouverture des sources de ASP.NET MVC est pour sa propre communauté : pendant trop longtemps l'innovation, la correction de bugs et les extensions ont été limitées à ce que les développeurs de Microsoft faisaient, pouvaient faire, ou étaient en mesure de spécifier. Cela ramènera ASP.NET au niveau d'autres frameworks open source qui ont évolué rapidement et répondent rapidement aux changements.
InfoQ : En ce moment, il y a quatre technologies d'interface utilisateur basées sur XAML: WPF, Silverlight, Silverlight pour Windows Embarqué et Silverlight pour Windows Phone. Avec l'introduction de Windows 8, nous allons peut-être en voir une cinquième version ? Quelle est votre opinion de cette diversification ?
Miguel: Nous sommes actuellement concentrés sur C # pour Android, iOS et Mac donc nous n'avons pas tendance à interagir beaucoup avec des cadres fondés sur XAML.
Il y a des facettes intéressantes à XAML, mais je n'ai jamais été complètement convaincu par XML à cause du balisage. J'ai souhaité pendant très longtemps qu'ils adoptent quelque chose de plus simple à produire, comme JSON pour le balisage ou le balisage qui faisait partie de JavaFX. Il était tout aussi facile à consommer et à maintenir, mais le code était également plus lisible pour les développeurs et plus facile à taper.
A un moment nous avons implémenté un moteur de rendu open source qui était capable d'afficher les balises de Silverlight v3/4.
De nos jours, nous disons aux développeurs de partager leur application en deux : une couche de code réutilisable qui peut être utilisé dans toutes les plates-formes .NET / Mono et une autre couche qui implémente la couche de présentation. Soit une interface native pour iOS, Android, Mac ou Windows, ou une version HTML.
InfoQ : Beaucoup de développeurs se tournent vers des plates-formes comme PhoneGap pour unifier le code de leur interface utilisateur sur toutes les plates-formes. Imaginez-vous possible pour C # de disposer également d'une bibliothèque d'interface utilisateur qui puisse fonctionner sur iOS, Android et Windows Phone ?
Miguel : Il y aura un mélange de tout cela.
Parfois, vous avez un budget serré, et vous utilisez une couche de présentation qui s'exécute sur tous les environnements à partir d'un unique code. Cela a bien marché our Java et nous l'utilisons nous-mêmes pour certains de nos outils avec Gtk # ou les bibliothèques Xwt.
Mais parfois vous voulez offrir la meilleure interface utilisateur possible, et pour cela vous devez écrire du code natif personnalisé. Nous avons aussi fait cela avec d'autres de nos outils, comme notre nouveau système de documentation pour Mono qui est désormais natif sur chaque plate-forme.
En particulier dans l'espace Mac et iOS, les utilisateurs accordent une grande importance à la qualité de finition et à l'utilisation d'interfaces natives, c'est pourquoi une interface utilisateur multi-plates-formes n'offrirait pas vraiment la meilleure expérience aux utilisateurs.
InfoQ : Avant le rachat de Novell, certaines personnes travaillaient sur le portage de Moonlight sur des tablettes Android. Ces travaux sont-ils toujours en cours ?
Miguel : Nous avons abandonné Moonlight.
InfoQ : Je suis désolé de l'entendre, Moonlight avait l'air très prometteur. Était-ce juste un manque de main-d'oeuvre ou pensez-vous qu'il n'y a plus d'avenir pour le navigateur basé sur Silverlight / Moonlight ?
Miguel : Silverlight a été peu utilisé sur le web, il n'est pas devenu la technologie "must-have" que je pensais qu'il allait devenir.
Et Microsoft a ajouté des restrictions artificielles à Silverlight qui l'a rendu inutile pour la programmation hors ligne.
Désormais, nous ne considérons plus Silverlight comme une plate-forme adaptée à une technologie « write once, run anywhere » (écrivez une fois, utilisez partout), il y a tout simplement trop de limites pour qu'elle soit utile. Ces jours-ci, nous pensons que, dans le monde C# la meilleure option est de séparer le code à la frontière de la couche de présentation. L'utilisateur pourra réutiliser le noyau essentiel de leur application sur toutes les plates-formes, et écrire une nouvelle interface spécifique pour chacune des plates-formes qu'ils ciblent : iOS avec MonoTouch, Android avec MonoDroid, Mac avec Monomac, Windows avec WPF ou Winforms ou Mac, Web avec ASP. NET et Windows et Linux avec GTK.
Ce n'est pas du « write once, run anywhere », mais on obtient des applications qui peuvent exploiter les fonctions natives et créer des expériences natives sur chaque plate-forme.
InfoQ : Si vous aviez plus de volontaires pour les parties open source de Mono, sur quels domaines voudriez-vous qu'ils travaillent ?
Miguel : Je dirais le travail sur les prochaines API v4.5 et WCF.
Microsoft a mis à jour plusieurs de leurs API .NET pour qu'elles soient prêtes pour le C# 5 asynchrone. Bien que nous ayons fait le travail sur les classes des librairies de base, je serais personnellement ravi de voir System.Data (et ses dérivés comme nos fournisseurs SQLite) enfin prêt pour l'asynchrone ainsi que la pile ASP.NET qui supporte désormais un pipeline asynchrone dont les développeurs peuvent tirer profit.
Les améliorations ASP.NET sont nécessaires pour tirer partie de tout le code ASP.NET que Microsoft a récemment ouvert. Sans ces changements, Mono ne pourra utiliser environ que la moitié du nouveau code libre, ou sera limité par ce qu'il peut réutiliser.
InfoQ : Je suppose que vous avez suivi le procès Oracle/Google sur l'API Android. Quel est votre avis sur la situation ?
Miguel : Cela ressemble à une guerre, et après les premiers coups, plus personne n'est innocent ni ne fait bonne figure. L'affrontement a entâché la réputation des deux entreprises.
InfoQ : Etes-vous inquiet que, si ces API tombent passent sous droit d'auteur, Microsoft menace le projet Mono ?
Miguel : Non.
Dans le débat Google/Oracle la question porte sur certaines API noyau, car aucune des API de haut niveau n'a atteint le point où elles seraient utiles dans cette lutte de plusieurs milliards de dollars. Google a choisi de ne pas adopter les parties de plus haut niveau car ils avaient besoin d'un autre ensemble d'API plus adaptées pour Android.
Dans le monde Mono/.NET, le droit d'auteur du noyau de l'API a été accordé à ECMA/ISO pour la distribution et je doute de l'utilité des API de plus haut niveau pour créer une industrie de plusieurs milliards de dollars. Si un commerce de plusieurs milliards de dollars devait émerger autour .NET / Mono, il utiliserait probablement le noyau, et supprimerait tous les trucs de haut niveau. Un peu comme nous l'avons fait pour MonoTouch et MonoDroid : nous utilisons le noyau, mais n'exposons aucune des API haut niveau Windows que nous remplaçons par des API native d'Apple ou d'Android.