Développeur : Sortie de XulRunner 1.8.0.1
Posté par Laurent J (page perso, ). Modéré le 03 février 2006.
XulRunner est un framework d'application multi-plateforme, basé sur les technologies Mozilla. Il contient donc le moteur Gecko 1.8 et une multitude d'APIs. XulRunner permet donc un développement rapide et le lancement d'applications réalisées avec les technologies XUL, XHTML, SVG, CSS, Javascript, XBL et bien d'autres encore.
Cette version est basée sur le même code que celui de Firefox 1.5.0.1. C'est en quelque sorte un Firefox amélioré livré sans son interface. À terme les produits Mozilla utiliseront XulRunner (Firefox 3, en 2007, motorisé par Gecko 1.9). Ils partageront donc les mêmes bibliothèques, facilitant les installations, les mises à jour et permettant d'économiser des ressources systèmes.
XulRunner est surtout destiné aux développeurs pour le moment, vu le peu d'application qui existent. La version finale 1.9 en 2007 fournira un système d'installation et de déploiement pour les applications XUL et une API plus complète.
![[en]](../images/en.png)
News sur Devnews (306 hits)![[fr]](../images/fr.png)
XulRunner sur Xulfr (2009 hits)-
XulRunner sur DevMo (512 hits)
-
Tutoriel XUL (842 hits)
-
Les technologies de XulRunner (645 hits)
-
XUL sur Wikipédia (484 hits)
> Lire la dépêche (39 commentaires, moyenne: 4,8).
Vous avez demandé le commentaire #678008.
Run by 
Cette page a été générée par Templeet en 0.0715s (dont 0.0071 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Stabilité de l'API
J'ai cru comprendre que l'api avait une facheuse tendance à beaucoup bouger et à multiplier les incompatibilités de version à version.
Qu'est-ce qu'il en est en ce moment?
Deuxio: je fais tourner un thunderbird, un firefox, un truc et un machin xul : est-ce que cela va utiliser 4 moteurs xul différents?
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: Stabilité de l'API
Pour l'instant oui... (peut-être seulement 3 moteurs xul néanmoins : les xulrunners se partageant la plus grosse partie de leur code) :(
Mais l'objectif est à terme de tout passer sur XulRunner et ainsi de faire de sacrés économie de ressource.
--
Jedaï
[^]Re: Stabilité de l'API
Oui, d'une version de gecko à l'autre, l'api évolue. C'est normal (cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps).
C'est le cas à l'heure actuelle, puisque chaque executable a son propre gecko. Avec Xulrunner ce n'est en principe pas le cas : chaque appli utilisant le même executable (xulrunner), donc les bibliothèques de xulrunner ne sont chargés qu'une fois en mêmoire.
[^]Re: Stabilité de l'API
> Oui, d'une version de gecko à l'autre, l'api évolue. C'est normal (cite
> moi une seule plateforme, un seul framework dont l'api ne bouge
> pas dans le temps).
OpenStep ?
Il y a bouger et bouger...
Si l'on regarde les gros projets, il casse la compatibilité ascendante de temps en temps mais essayes de l'éviter tous les quatres matins.
Pour en revenir a OpenStep, on ne peux pas dire que ce soit dépassé et moche (cf MacOSX), et ca contine aussi d'évoluer. Dommage qu'il ne semble pas y avoir de binding connus vers les langages de scripts car je suis sur qu'il y gagnerais (j'ai bien vu une libcamelbones0 sur ma debian mais je ne sais ce que ca vaut). Je pense notament à ruby que je connais très peu mais qui semble proche d'ObjectiveC dans sa philosophie.
[^]Re: Stabilité de l'API
>Dommage qu'il ne semble pas y avoir de binding connus vers les
>langages de scripts car je suis sur qu'il y gagnerais
Perl : Camelbones http://camelbones.sourceforge.net/
Python : PyObjc http://pyobjc.sourceforge.net/
Ruby : RIGS http://www.gnustep.org/experience/RIGS.html
Scheme doit trainer aussi quelque part
Non interprété :
C : naturel ( ObjC est une surcouche de C )
C++ : ObjC++ dans gcc-4.X ?
JIGS : java
Il faut savoir que CamelBones / PyObjC ne fontionne pas très bien avec GNUstep actuellement et que RIGS ne passe probablement pas sur Cocoa...
[^]Re: Stabilité de l'API
Pense a Linux qui modifie regulierement les interfaces d'acces pour une partie du materiel (et qui a pose des problemes dans le cas du support des webcams philips il me semble).
Et dans le cas qui nous interesse, XULRunner est une version en developpement, donc il est normal que ca evolue sans cesse.
[^]Re: Stabilité de l'API
Justement, linux est un mauvais exemple. Les noyaux 2.6 sont vraiment "chiant" au niveau des serveurs. D'ailleurs, j'ai certains serveurs encore en 2.4 car avec lui, pas de surprise ni de reboot du serveur tous les mois. Lors d'une mise à jour du noyau pour cause de trous de sécurité, tu es sur qu'il reboote bien.
Le problème avec les noyaux 2.6, c'est que pour un non spécialiste de la programmation du noyau, on avance un peu trop à l'aveuglette et parfois sans filet...
[^]Re: Stabilité de l'API
cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps
L'API doit évoluer, certe, mais en gardant une certaine compatibilité. Imagine un peu le problème si Java 1.5 n'était pas compatible avec java 1.4 qui n'était pas compatible avec Java 1.3, etc. Ou pire imagine si la libc changeait tous les ans :)
MonoFrance
[^]Re: Stabilité de l'API
C'est un peu ce que je voulais dire :-)
Ceci dit tant qu'il y a pas des cent et des mille d'applications en xul on peut toujours évoluer bien sûr, et d'une certaine manière c'est un choix, entre la compatibilité et l'évolution.
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: Stabilité de l'API
> L'API doit évoluer, certe, mais en gardant une certaine compatibilité.
C'est ce qui se passe dans Gecko quand même. Ça évolue, mais les corrections pour adapter à chaque nouvelle version de gecko sont mineures tout de même. Et puis bon, comparer Gecko à Java, c'est tout de même un peu oser : Java est quand même plus mature que les technologies incluses dans Gecko. Il est donc normal que l'API de Java soit un minimum stable ;-)
Et à l'avenir, ce sera pareil pour Gecko, une fois que tout sera suffisement mature (et ça commence à l'être, d'où XulRunner), l'API sera stable. Nombre d'interfaces IDL sont marquées "FROZEN" dans Mozilla, et ce nombre va augmenter pour la version public stable de XulRunner (1.9)
[^]Re: Stabilité de l'API
Les règles qui ont été adoptées dans le domaine aéronautique et spatial sont bâties sur la notion d'interchangeabilité. Quand elle est rompue, c'est un changement de version majeure. J'ai l'impression que dans le monde du logiciel, il serait bon d'utiliser les même règles.
[^]Re: Stabilité de l'API
Je pense qu'il faut distinguer 3 types d'API.
L'API coté XPFE (XUL & co)
L'API XpCom
L'API interne à Gecko
Suite à mes différentes expériences, je peux dire que:
L'API XPFE reste bien évidement stable pour tout ce qui est standardisé (XHTML, CSS, SVG, ...). Pour ce qui ne l'est pas (XUL) c'est vrai qu'il y a des améliorations (richbox par exemple) et des modifications (les colonnes des arbres). Ce ne sont pas des évolutions violentes de l'API. Cela n'a pas demandé énormément de travail de faire évoluer une application basée sur Gecko 1.7 à Gecko 1.8 (coté XPFE). Pour ce qui est de l'enregistrement chrome (disons rapidement la manière de packager) c'est vrai quelle a beaucoup changée, mais la méthode actuelle risque bien du durer un bout de temps :)
Au niveau de l'API XpCom, rien de bien nouveau entre Gecko 1.7 et 1.8, à part peut être l'API des strings, simplement parce que l'on a switché d'API par défaut (il y l'API frozen et internal). Avant on utilisait l'internal par défaut, maintenant la frozen (je n'ai pas du tout suivi le pourquoi de la chose), on peut facilement faire remonter l'internal (avec un #define en plus), et on est compatible. Mais bon, tant qu'à faire, on préfère passer son code en Frozen, et dans ce cas, c'est 2/3 noms de types qui ont changés.
L'API interne (le code du moteur), là il y a débat à savoir si elle doit être clairement considérée comme une véritable API claire et stable. Je ne la connais pas bien, mais ce ne doit pas être très strict. Pour plus dinfos, voyez les questions que se posent les gens qui connaissent:
http://glazman.org/weblog/dotclear/index.php?2005/11/16/1383(...)
http://benjamin.smedbergs.us/blog/2005-11-17/the-internals-o(...)
Pour conclure, il faut voir que Gecko est une plateforme jeune et que l'on peut dire que sa version 1.8 est une version ayant pour ambition d'être exploitée par bien d'autres softs que simplement Firefox et Thunderbird, ce qui anonce un réel effort de s'orienter vers les développeurs (après le grand public, les développeurs).
[^]Re: Stabilité de l'API
Je ne comprends pas très bien ce paragraphe (ou plutôt j'en vois plusieurs interprétations). Si quelqu'un pouvait m'éclairer...
Est-ce que Xulrunner sera :
-(1) une bibliothèque partagée liées aux diverses application (firefox, ...)
-(2) un "demon" lancé par l'utilisateur utilisé par firefox, ... (communication par socket, mémoire partagée, ...)
-(3) une application qui charge dynamiquement les "modules" souhaités (firefox, ...)
Les trois formes permettent de partager le code en mémoire. Par contre, (2) nécessite d'avoir un logiciel vraiment déboggué (je n'ai pas envie que le plantage de "firefox" plante le demon et par suite les autres appli xul). (3) est encore pire puisqu'il faut que toutes les applis xul soient sans bug.
[^]Re: Stabilité de l'API
ni l'un ni l'autre.
si j'ai tout bien compris
xulrunner est une application qui charge le module souhaité
xulrunner est exécuté indépendamment pour chaque exécution avec un truc du type "xulrunner monapplication"
un peu comme java si tu veux
l'intérêt c'est que toutes les bibliothèques peuvent être partagées, mais chaque application a sa propre instance de xulrunner
[^]Re: Stabilité de l'API
<< cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps >>
win32: tu peux encore compiler tes programmes windows 3.1 aujourd'hui, ils fonctionnent toujours. Ca doit faire dans les 15 ans de plate-forme stable. C'est d'ailleurs une des forces de windows.
Sinon, on peut citer gtk, Gnome, KDE et Qt, dont les versions sont entierement compatibles entre elles si on ne change pas le premier chiffre. On tape dans les 3-4 ans de stabilite. Et deja avec 3-4 ans, ce n'est pas suffisant, il y a pas mal d'applications qui ne sont jamais portees et sont en quelque sorte perdues. Sous windows, ca m'arrive d'utiliser des applis qui clairement ont ete ecrites pour windows 3.1 et qui fonctionnent tres bien.
Tout ca pour dire que la stabilite des APIs, ce n'est pas un truc a prendre a la legere et que les faire varier meme de facon mineures tous les 6 mois, c'est le meilleur moyen de tuer un projet.
phil.freehackers.org
[^]Re: Stabilité de l'API
bonne nouvelle : ça fait 7 ans que la plateforme mozilla existe ;-)
Plus serieusement, la plateforme était jusqu'à il y a 2-3 ans utilisé exclusivement par Mozilla pour la suite, Firefox &co. C'est pour cela qu'il ne se souciait pas de la stabilité au niveau API. Maintenant que la technologie est mature et utilisée par de plus en plus de monde, il est certain qu'ils vont tout stabiliser.