 |
|
| |
 |
Michael Gerard
Développeur
SongBird |
|
Michael Gerard (SongBird)
"Si Mozilla ne pousse pas XUL Runner en avant, XAML prendra le dessus facilement"
Ancien de Winamp et lead developer du lecteur de média SongBird construit avec XUL Runner, Michael aborde les développements XUL, les relations avec Mozilla et la concurrence future du XAML de Microsoft.
03/04/2006 |
| |
 |
|
Quelles sont les technologies utilisées au sein de SongBird ?
Michael Gerard Nous utilisons avant tout trois projets très connus : XUL Runner pour la plate-forme elle-même, SQLite pour gérer la bibliothèque de médias, et le plugin VLC de Mozilla. Nous utilisons également l'API XPCOM pour décrire les encapsulateurs JavaScript pour les autres plug-ins de lecture - mais pour l'heure, il n'y a que VLC.
XUL Runner était loin d'être en version finale quand vous-même avez sorti votre première version. Comment vous êtes-vous pris pour l'utiliser alors même qu'il était en développement ?
Pendant le développement initial de SongBird, Gecko 1.9 était plus stable que XUL Runner. En réalité, nous n'avons pas vu beaucoup de changements dans XUL Runner depuis notre lancement, il y a 9 mois. Nous y avons trouvé de nombreux bugs, et en avons vu beaucoup être corrigés, comme la reconnaissance Unicode dans l'API de fichier de Mozilla. Nous l'avons vu se transformer, mais sans grand changement. XUL Runner fonctionnait suffisamment bien dès notre lancement.
Combien de personnes et de temps le développement a-t-il nécessité ?
Nous avons commencé en juillet 2005, avec quatre personnes et mon patron, Rob Lord. Nous étions deux développeurs, Ghislain Lacroix et moi-même. Le premier mois et demi s'est passé sur un wiki, à construire la structure de ce que nous allions faire. Nous ne sommes réellement mis à coder qu'à partir de septembre. Depuis lors, nous avons embauché entre autres deux programmeurs XUL, et Francis Gastellu [NDLR : ancien de l'équipe d'habillage de Winamp, tout comme Michael Gerard, Ghislain Lacrois ou Rob Lord]. Donc, nous sommes 5 programmeurs, et nous allons passer à 10 d'ici 3 à 4 mois, si nous obtenons le budget nécessaire.
|
|
 Notre idée première était bien de créer l'ultime API de lecteur de médias" |
|
Cette API était-elle prévue, ou est-ce un heureux à-côté de votre travail ?
Notre idée première était bien de créer l'ultime API de lecteur de médias, pour faciliter à tous la construction de leur propre interface de lecteur, tout en étant automatiquement compatible avec toutes les extensions créées pour SongBird. Par "tous", j'entends les partenaires qui nous paient pour être la base de leur lecteur, ou peut-être les habilleurs d'interface à la Winamp 5, qui donnent une toute nouvelle interface aux utilisateurs de SongBird.
Le plus gros de l'API est destiné, bien entendu, à ouvrir de nouvelles possibilités aux programmeurs d'extensions, et aux développeurs d'applications HTML distantes grâce à un sous-ensemble de nos fonctionnalités accessibles aux pages non sécurisées.
Quelle fut la partie la plus compliquée à développer ?
Avant tout, l'habillage, avant même que nous ayons écrit l'inspecteur de DOM. Les extensions elles-mêmes ne sont pas encore conçues pour comprendre XUL, donc l'inspecteur de DOM a dû être écrit en tant qu'extension XUL. Nous avons dû passer par XBL pour pouvoir réaliser l'habillage correctement.
Les extensions ne sont pas faites pour comprendre qu'elles peuvent être chargées dans un logiciel basé sur la plate-forme XUL. Elles sont toutes spécifiques à une application. Nous avons donc dû passer beaucoup de temps sur l'inspecteur de DOM, pour le faire fonctionner sous SongBird.
Avez-vous utilisé ou construit des outils pour accélérer le codage XUL ?
Nous faisons tout notre code XUL à la main. C'est notre premier projet XUL, mais nous avons tous utilisé XML pour décrire des interfaces depuis plus ou moins 5 ans. L'idée de base reste équivalente pour tous les systèmes, il devient alors facile d'apprendre une nouvelle syntaxe. Le codage à la main n'est donc pas vraiment un problème.
Que pensez-vous de l'arrivée prochaine de XAML ?
Une fois que Microsoft aura sorti XAML et Sparkle, ils vont largement dépasser les capacités de XUL, parce qu'ils auront les outils qui accompagneront la technologie. Mozilla doit vraiment capitaliser sur XUL Runner et l'étendre, car si tout ce que XUL a pour lui est l'aspect multiplate-forme, les développeurs lambda, ceux qui font des applications Win32 habituellement, l'oublieront pour utiliser XAML.
Nous espérons que d'ici là, Gecko sera capable d'afficher de la 3D, et que ses capacités d'affichage SVG deviendront acceptables pour que ceux qui comme nous utiliseront XUL puissent fournir des interfaces à peu près équivalentes à ce qu'offrira XAML. L'outil Sparkle va cependant largement changer la balance des pouvoirs. Il ne faut jamais s'opposer à Microsoft quand on en vient au support développeur.
|
|
Nous voulons montrer à Mozilla que ce dont ils ont besoin, nous en aurons besoin encore plus tôt qu'eux
." |
|
Avez-vous reçu de l'aide de la part de Mozilla ?
Nous avons eu un certain nombre de réunions sur IRC, pour des informations techniques de base. Nos questions les plus compliquées ont souvent fini dans Bugzilla.
Nous espérons un peu les forcer à voir que ce que nous faisons est positif. Une bonne partie de notre feuille de route pour la version 0.3 consiste en cela : leur montrer que beaucoup de choses dont Mozilla a besoin, nous en aurons besoin encore plus tôt qu'eux. Nous voulons, en travaillant avec eux, être sûrs de ne pas dupliquer les efforts ou interférer avec les plans technologiques de Mozilla.
Vous utilisez énormément XUL Runner, qui ne sera terminé que pour Firefox 3.0. Cela veut-il dire que SongBird 1.0 devra attendre cette date de sortie ?
J'espère que non. Nous avons beaucoup à faire. Nous avons plus de besoins en ressources que Mozilla n'est capable de mettre sur XUL Runner. Cela nous inquiète assez, en fait, et nous poussons Mozilla à mettre plus d'effort dans XUL Runner, mais nous nous préparons à l'éventualité de ne pas voir nos calendriers être synchrones.
Nous utilisons fortement BugZilla, et son système de vote : il nous arrive de demander à nos visiteurs de voter en faveur des bugs que nous pensons critiques pour nos propres avancées. Idéalement, la fondation Mozilla allouera plus de ressources à XUL Runner, mais en attendant, nous avons lancé des offres d'emploi autour de XUL.
Un grand nombre de nos problèmes communs est en fait la norme de toute collaboration entre deux projets Open Source.
En tant que projet Open Source à temps plein, comment gagnez-vous votre vie ?
Pour le moment, mon patron, Rob Lord, me paye.
Peut-on réaliser tout type d'application avec XUL ?
Vous pourriez même faire The Gimp facilement. The Gimp est un bon exemple d'interface utilisateur multiplate-forme facile à mettre en place, car elle ne varie pas beaucoup. Elle n'a donc pas vraiment besoin de XUL. La véritable valeur de XUL est sa capacité à utiliser le DOM standard en tant qu'API, et à créer des interfaces utilisateur dynamiques basées sur des jeux de données externes.
Microsoft propose par contre de bien meilleurs widgets ; ceux de XUL font vieux et bidouillés. Cela étant, j'estime que se repose volontairement sur Microsoft pour quoi que ce soit revient à se mettre volontairement une paire de menottes...
|
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
Michael Gerard, 34 ans, est architecte du projet SongBird
2005 Pioneers of the Inevitable, développeur pour SongBird
2004 Philips Electronics, ingénieur set-top-box
2001 Nullsoft / America Online, ingénieur sénior
1994 Quicksilver Software, ingénieur développement
|
|
|
|
|
|
|
Dossier 
