Après que WebKit ait emporté la première manche via le test Acid 3 [1], WebKit vient de marquer un nouveau point (de bien moindre importance, certes...). Les developpeurs du projet Epiphany, le navigateur web de GNOME, ont annoncé sur la mailing-list [2] qu'ils n'utiliseraient plus Gecko pour le rendu des pages web à partir de la prochaine version, numérotée 2.24, c'est à dire dans six mois.
Les raisons invoquées sont multiples :
- nouvelles versions de Gecko pas assez régulière
- API et fonctionnalités trop orientées vers Firefox, pas pensées pour les autres navigateurs
- API instable
- futur incertain de Gecko (version 2.0)
Mais la principale raison mentionnée dans l'annonce concerne le manque de temps. En effet, maintenir une couche de compatibilité avec plusieurs moteurs de rendu prend du temps et l'équipe d'Epiphany en manque. De plus, cette couche d'abstraction complexifie le code.
Le principal avantage apporté par WebKit est une meilleure intégration à GNOME : l'API est "GObject", le rendu des éléments graphiques et de la page est fait par GTK/Cairo et les éléments multimédia sont interprétés par Gstreamer. De plus, utiliser un seul moteur de rendu permettra d'avoir des extensions qui peuvent accéder directement à l'arbre DOM, ce qui permettra d'agir directement avec le contenu des pages.
Si les développeurs d'Epiphany font en sorte que WebKit devienne une dépendance de GNOME, alors d'autres projets GNOME devraient rapidement s'en servir. Par exemple Evolution qui pourrait l'utiliser comme moteur de rendu des emails HTML et comme éditeur pour la rédaction d'email en HTML. Yelp, qui est le système d'aide de GNOME, pourrait également s'en servir.
Les développeurs ont annoncé que s'ils n'arrivaient pas à terminer cette migration pour la sortie de GNOME 2.24, alors il n'y aurait pas de nouvelle version d'Epiphany dans GNOME 2.24 et qu'il faudrait alors patienter jusqu'à GNOME 2.26. Souhaitons leurs bon courage pour pouvoir rapidement profiter de Epiphany/WebKit !
[1] http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-p(...)
[2] http://mail.gnome.org/archives/epiphany-list/2008-April/msg0(...)
Vous ne pouvez plus rajouter de commentaires! (trop vieux)
Les raisons invoquées sont multiples :
- nouvelles versions de Gecko pas assez régulière
- API et fonctionnalités trop orientées vers Firefox, pas pensées pour les autres navigateurs
- API instable
- futur incertain de Gecko (version 2.0)
Mais la principale raison mentionnée dans l'annonce concerne le manque de temps. En effet, maintenir une couche de compatibilité avec plusieurs moteurs de rendu prend du temps et l'équipe d'Epiphany en manque. De plus, cette couche d'abstraction complexifie le code.
Le principal avantage apporté par WebKit est une meilleure intégration à GNOME : l'API est "GObject", le rendu des éléments graphiques et de la page est fait par GTK/Cairo et les éléments multimédia sont interprétés par Gstreamer. De plus, utiliser un seul moteur de rendu permettra d'avoir des extensions qui peuvent accéder directement à l'arbre DOM, ce qui permettra d'agir directement avec le contenu des pages.
Si les développeurs d'Epiphany font en sorte que WebKit devienne une dépendance de GNOME, alors d'autres projets GNOME devraient rapidement s'en servir. Par exemple Evolution qui pourrait l'utiliser comme moteur de rendu des emails HTML et comme éditeur pour la rédaction d'email en HTML. Yelp, qui est le système d'aide de GNOME, pourrait également s'en servir.
Les développeurs ont annoncé que s'ils n'arrivaient pas à terminer cette migration pour la sortie de GNOME 2.24, alors il n'y aurait pas de nouvelle version d'Epiphany dans GNOME 2.24 et qu'il faudrait alors patienter jusqu'à GNOME 2.26. Souhaitons leurs bon courage pour pouvoir rapidement profiter de Epiphany/WebKit !
[1] http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-p(...)
[2] http://mail.gnome.org/archives/epiphany-list/2008-April/msg0(...)
> Lire le journal (41 commentaires, moyenne: 2,4).
Run by 
Cette page a été générée par Templeet en 0.0381s (dont 0.0028 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: Non
Toi tu es un champion et tu insistes.
Tu confonds aussi complexité de la "pile logicielle" et complexité d'un de ses composants.
Peut-être que la complexité de la pile logicielle dépend de la complexité de ses composants? Là tu fais dans le lamentable. Dsl, j'ai pas fait polytechnique mais ça j'arrive à le comprendre.
D'un autre côté, tu confonds bien le fait de faire interpréter un langage script dans une VM et le fait de faire tourner du byte code directement dans une VM, d'où tes jérémiades concernant la "porte ouverte aux applis proprios"...
Relis mes commentaires:
Il ne faut pas que le web s'approche d'une VM à bytecode (le pire sont celles à registres). Car cela augmente énormémement le risque d'application proprio web. Ce n'est pas de savoir comment elle va être utililsée qui est important, mais juste le fait qu'elle soit là.
De plus la performance d'une interface web graphique n'a pas besoin de s'encombrer de la complexité d'une VM, un bête interpréteur doit suffire, au pire tu rajoutes des structures de données plus riches et tu as des méthodes pour bosser dessus cablées en C/ASM optimisées de la mort qui tue dans l'interpréteur.
Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Bon là tu ne me fatigues plus... tu m'as tué... ras le bol.
[ Répondre ]