News Xulfr

L'avenir des extensions

mardi 30 mars 2010 à 12:19

Hier soir, des développeurs XUL, dont l'équipe Xulfr, étaient invités à rencontrer et à discuter avec Chris Beard (Chief Innovation Officer chez Mozilla) et Nick NGuyen (Director of Add-ons chez Mozilla), qui étaient de passage à Paris. Suite à certaines annonces malencontreuses par le passé, cela a donc été l'occasion d'en savoir plus sur le futur des extensions.

Comme vous le savez certainement déjà, Mozilla expérimente depuis plusieurs mois un nouveau système d'extension, JetPack, qui se veut plus facile à utiliser, et qui facilite grandement le développement. Il propose une API javascript pour apporter des nouvelles fonctionnalités au navigateur. Il n'y a plus de XUL, plus d'overlays, mais une api JS et l'utilisation du HTML. Le développeur réalise grosso modo une page web, dans lequel il met le code javascript de son extension et les éléments d'interfaces. L'api JS permet d'ajouter des boutons ou autres éléments d'interface à divers endroit de Firefox (status bar, toolbar...), mais aussi d'accéder aux bookmarks, de manipuler les pages web ouvertes etc..

Jusqu'à il y a peu, Jetpack était livré sous forme d'extension xpi (que vous pouvez toujours utiliser), ceci afin d'expérimenter cette nouvelle façon de faire des extensions. Mais le projet connaît actuellement une refonte complète, afin de tenir compte des remarques et des problèmes existants dans les prototypes précédents. Cette refonte a donné naissance au JetPack SDK, qui, comme son nom l'indique, n'est plus une extension mais un ensemble d'outils et de bibliothèques pour réaliser une extension "à la jetpack".

Il y a quelques semaines, des annonces avaient fait croire que Jetpack allait remplacer totalement le système d'extension actuel. Et cela avait créé des mécontentements parmi les développeurs d'extensions. En effet, même si Jetpack est une bonne chose pour Firefox, car il évitera de sortir l'artillerie lourde pour afficher seulement 2 boutons et exécuter 15 lignes de codes, le développeur n'aura pas la même liberté qu'avec le système actuel. En effet, avec Jetpack, le code de l'extension est "enfermé" dans une boite. Il ne peut faire que ce que l'API de jetpack lui permet de faire. Contrairement au système actuel où le développeur fait ce qu'il veut, modifie l'interface de Firefox comme il le souhaite, peut utiliser toutes les API internes de Gecko, et même jusqu'à fournir ses propres bibliothèques binaires (dll etc..). Bref, avec la suppression du système d'extension xpi , on serait passé d'un système totalement ouvert, facilitant grandement l'innovation, à un système limité.

Mais il y a eu par la suite des démentis "officiels", et Chris et Nick l'ont encore confirmé hier soir à cette réunion : le système actuel ne disparaîtra pas, et il cohabitera avec le nouveau système jetpack.

Le développeur d'extensions aura donc le choix :

  • Il utilisera jetpack si en terme de fonctionnalités proposées, cela lui convient, et qu'il a envie d'utiliser une API simplifiée. À priori, 80 à 90% des extensions actuelles pourraient être développées avec Jetpack.
  • Il développera une extension XPI, avec XUL, les overlays, les XPCOM etc, si il a besoin d'aller au delà de ce que lui propose JetPack.

Parallèlement au développement de Jetpack, le système d'extension XPI va connaître des évolutions. En particulier, la possibilité d'installer une extension sans avoir à redémarrer Firefox. Cela profitera également à Jetpack, car Nick nous a expliqué hier qu'une extension jetpack sera probablement packagé sous la forme... d'un XPI ! D'autres idées sont aussi à l'étude, comme la fusion du contenu des fichiers chrome.manifest et install.rdf, en un fichier au format json. Et voir même la disparition des fichiers manifest chrome, en imposant une arborescence dans l'archive. Le système d'extension devinera ainsi tout seul où se trouve la partie "content", "locale" et "skin".

Tout ceci est encore en réflexion ou en début de développement. Nous vous tiendrons bien sûr au courant des évolutions.

Par Laurent Jouanneau :: Technologies :: #292 :: rss

Trackbacks

1. mardi 30 mars 2010 à 13:36 de uberVU - social comments

Social comments and analytics for this post

This post was mentioned on Identica by ljouanneau: Pour les dev XUL: l'avenir des extensions dans Firefox http://xulfr.org/news/2010/03/30/292-l-avenir-des-extensions

2. mercredi 14 avril 2010 à 02:40 de Lagon Libre

Quoi de neuf dans la communauté Mozilla francophone depuis 3 semaines ?

Déjà 3 semaines depuis mon dernier billet. Il ne s'est pourtant pas rien passé depuis Solutions LInux. Côté technique Lundi 29 mars, des développeurs XUL, dont l'équipe Xulfr, étaient invités à rencontrer et à discuter avec Chris Beard...

Les trackbacks pour ce billet sont fermés.

Commentaires

1. mardi 30 mars 2010 à 15:18, par Nicolas Froidure

La preuve de la supériorité du système XUL à JetPack est qu'il existe déjà une extension pour installer les extensions Google Chrome sur Firefox. L'inverse sera probablement jamais vrai.

JetPack, c'est une réponse au système d'extension de Chrome, mais c'est pas parce que Google a fait un mauvais choix que Mozilla doit faire de même ;). Content qu'ils aient reconsidéré la question après que le soufflet Chrome soit retombé.

2. mardi 30 mars 2010 à 16:05, par Paul

@Nicolas Supérieur, évidement (on n'a jamais dit le contraire), mais beaucoup plus compliqué. Sinon, JetPack n'est pas la réponse à ce que fait chrome. On a créé JetPack *avant* Chrome. Et puis on a rien reconsidéré du tout, c'est juste vous qui commencez à comprendre :)

3. mardi 30 mars 2010 à 18:42, par Nico

@Paul : Niveau complexité, franchement, je doute. Ou alors, si on commence à faire des composants XPCom, mais la question est pas de savoir si parmi tout ce qui est possible de faire, une partie est compliquée.

Empaqueter un xpi, c'est simple, le javascript, tout le monde connaît et XUL, dans l'absolu, c'est plus simple que HTML car les styles prédéfinis permettent de faire des interfaces facilement sans styler chaque élément comme on devrait le faire avec HTML. Je trouve plus simple de faire une application web avec XUL qu'avec HTML. Certainement parceque XUL est fait pour ça.

Pour le contexte de JetPack, c'est l'impression qu'on a eu, sûrement un quiproquo ;). L'important, c'est le résultat.

Sinon, pour remplacer XUL par XHTML5 (à terme, j'imagine que ce sera l'objectif de Mozilla), je pense qu'une solution serait de faire des styles prédéfinis adaptés à la conception d'UI et assurer la rétrocompatibilité pour les devs d'extensions avec une transformation XSLT du XUL vers ce XHTML "formaté" pour la conception d'interface web.

Qu'en penses-tu ?

4. mercredi 31 mars 2010 à 00:48, par Thierry

@Paul : "rien reconsidéré du tout"... il me semble pourtant que Mozilla n'est pas très satisfait du modèle d'extensions actuel du point de vue sécurité, problème beaucoup plus simple à gérer avec le modèle Jetpack. Je ne serais vraiment pas étonné de les voir envisager la fin du support de celles-ci sitôt l'envol de Jetpack...

5. mercredi 31 mars 2010 à 05:58, par Raph

Si les extensions XUL disparaissaient, ce serait plutôt catastrophique pour moi : Je construis des applications basées sur XULRunner et fonctionne avec des extensions XUL dédiées... Jetpack ne me servirait donc à rien et je perdrais mon gestionnaire d'addons non ?

6. mercredi 31 mars 2010 à 10:40, par Paul

@Nico Si. manifest + structure chrome + rdf, franchement, c'est pas évident quand on veut juste rajouter un bouton qui exécute 15 lignes de code (comme dit Laurent). Pour HTML5 je ne comprends pas.

@Tierry Je parlais de reconsidérations de JetPack lui-meme. Mais de toute manière, je t'assure à 100% que si on abandonne le systeme actuel (ce dont je doute très fort) c'est pour quelque chose d'au moins aussi puissant et compatible avec l'existant (donc pas JetPack).

@Raph On n'abandonne rien du tout. On n'est pas stupide non plus :)

7. mercredi 31 mars 2010 à 11:13, par Laurentj

@nico : non, développer une extension n'est pas simple pour beaucoup de développeur. déjà, rien que les install.rdf et chrome.manifest sont rebutants à écrire, comme l'a dit Paul.

Ensuite, ok, on arrive facilement à utiliser XUL, CSS et cie au début, mais dés qu'il faut attaquer des xpcoms, utiliser le systeme de commande (commands updater et cie), les templates XUL et autres fonctions avancées (mais souvent indispensables), la courbe d'apprentissage devient plus rude. Et souvent pour un gain faible (ie: faire des trucs qui à priori devraient être simple, ne le sont finalement pas pour un débutant).

D'où Jetpack pour faire des extensions qui ne demandent pas de connaître les internals de gecko.

Mais maintenant, remplacer XUL par HTML5, non, par pitié, HTML5 n'est toujours pas fait pour faire une interface propre, même si le modèle de boite XUL est un module CSS3 et implémenté dans gecko et webkit. Il manque encore un gros pavé : XBL dans tout les navigateurs (la majorité des tags XUL sont des XBL).

@thierry : non, le système actuel restera pendant encore longtemps. On a eu maintes confirmations ces derniers mois, et encore à cette réunion. Ce serait totalement contre productif (pertes d'extensions), et limiterait les innovations. Jetpack est et restera toujours aussi cloisonné, pour les raisons de sécurités dont tu parles. Donc Jetpack sera toujours trop limitant pour faire certaines extensions. Faire par ex un truc qui utilise des apis internes comme Firebug, sera impossible avec Jetpack.

8. mercredi 31 mars 2010 à 13:53, par Thierry

@Paul,Laurentj: merci pour vos réponses. Je suis également rassuré par l'implication de Mozilla dans les xpi (possibilité d'installer une extension sans avoir à redémarrer Firefox).

Les commentaires pour ce billet sont fermés.

Copyright © 2003-2013 association xulfr, 2013-2016 Laurent Jouanneau - Informations légales.

Mozilla® est une marque déposée de la fondation Mozilla.
Mozilla.org™, Firefox™, Thunderbird™, Mozilla Suite™ et XUL™ sont des marques de la fondation Mozilla.