0
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(...)
> Lire le journal (41 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #918888.
Run by 
Cette page a été générée par Templeet en 0.1129s (dont 0.0122 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
erreur
>- futur incertain de Gecko (version 2.0)
Mouai, ils se sont franchement pas casser le cul à se documenter sur le sujet.
Parce que si ils s'étaient renseigné un peu sur Mozilla 2, ils auraient su qu'un des objectifs majeurs de Mozilla 2, c'est de simplifier encore plus l'embarquement de gecko dans les applis tiers, avoir quelque chose de plus propre, plus léger, avec le support XPCOM supprimé en interne etc... Car il faut savoir qu'un autre objectif principal de Mozilla 2, c'est Mozilla Mobile, autrement dit l'utilisation de Gecko dans l'embarqué.
Bref, donc en gros, Mozilla 2 correspondra beaucoup plus à leurs exigences. C'est une très mauvaise raison qu'ils ont donné là.
[^]Re: erreur
Si tu as le temps, est-ce qu'il te serait possible de nous founir les liens sur la Mozilla 2 road map?
C'est juste histoire de nous mâcher le travail...
[^]Re: erreur
http://wiki.mozilla.org/Mozilla_2
http://wiki.mozilla.org/Mobile
[^]Bravo!
Exactement ce qu'il ne fallait pas faire! Une VM pour le web! Cela va apporter son lot d'applications web riches proprios.
Hum la belle m... qu'ils nous préparent pour le web!
Un des seuls trucs sur la bonne voie comme spidermonkey et bien paff! Ils dropent ce qui était bien dedans pour recoder en C++.
Quand on voit les participants, et bien je ne remercis pas adobe car manifestement ce sont eux qui ont réussis à faire un coup d'état sur la communauté de mozilla.
Il semblerait que toutes ces mauvaises idées soient essentiellement les leurs. Faut dire je n'attendais pas plus de la part des personnes qui ont fait flash.
Je comprend *beaucoup* mieux pourquoi epiphany fuit gecko maintenant, puisqu'il semble très très mal tourner... remarque tu vas me dire qu'avec mono, gnome ça ne sent pas plus la rose non plus.
[^]Re: Bravo!
Peut-être qu'en fait, le C++ c'est bien.
[+] [^]Non
Écrit un compilateur C++ (pas d'optimisation). Juste le respect des spécifications du language (Faut qu'il encaisse Boost et la STL quand même).
Écrit un compilateur C (pas d'optimisation non plus).
Et là... miracle! Tu réalises pourquoi!
[^]Re: Non
Et écrit un "compilateur" d'assembleur, ou un compilateur brainfuck.....
Selon toi ça veux dire que tout le monde devrais coder en assembleur ou en brainfuck ?
C'est pas parce que le compilateur d'un language est plus simple à écrire que le language est plus adapté.
[^]Re: Non
Pourquoi quoi ? Qu'un langage compliqué à compiler est forcément moins bon qu'un autre plus simple à compiler ? J'aurais plutôt tendance à penser l'inverse. J'avais un prof d'algo qui disait souvent "plus c'est simple, plus c'est compliqué !"
[+] [^]Re: Non
Qu'un langage compliqué à compiler est forcément moins bon qu'un autre plus simple à compiler ?
Si tu te places dans le contexte qui consiste à considérer la complexité de l'ensemble de la pile logicielle dont dépend le programme en question, un langage délirant à mettre au point est évidement moins bon. Ça ne va pas chercher plus loin. C'est une priorité/une limite comme une autre.
Je suis un développeur soucieux de la simplicité de la totalité de la pile logicielle. Dans cette optique, il n'est pas possible de considérer le C++ et similaires car la complexité d'un compilateur C++ lambda est délirante donc explose les limites que je me suis imposées.
[^]Re: Non
Hmmm...
c'est beau, ces considérations à l'emporte-pièce et ce "délirant" asséné avec autosuffisance pour essayer de jeter le C++ à la poubelle... mais bon, c'est fréquent de vouloir discréditer les outils qui nous dépassent.
Tu sembles être un champion des faux prétextes en tout cas, ça et le discours concernant l'utilisation de VM ...
[^]Re: Non
Tu as tout à fait le droit de ne pas être d'accord sur ce genre de limites merci de le faire savoir.
Comme j'ai le droit de ne pas être d'accord avec les tiennes et de le faire savoir.
[^]Re: Non
Tiens, cette fois-ci je suis d'accord avec toi; Je ne supporte pas de manger mes haricots verts avec une fourchette de plus de 3 piques, alors c'est très difficile pour moi car en général elles en ont quatre et ça dépasse de manière délirante mes critères intrinsèques que je me suis imposés à moi-même et de façon personnelle.
[^]Re: Non
Belle analogie!
Je vais faire sur le même niveau mais avec l'excès dans l'autre sens:
"Je ne supporte pas de manger mon haricot vert si celui-ci n'est pas déposé dans ma bouche par la fourchette Two thousand and eight!
La fourchette Two Thousand and Eight vient livrée avec sa centrale nucléaire et son datacenter. Bien entendu au cas où la centrale nucléaire tchernobylerait, la fouchette Two Thousant and Eight est livrée en standard avec un backup à l'énergie solaire avec son rayon solaire viendant de l'espace avec son satellite géostationnaire intégré!
La fouchette Two Thousant and Eight, simplifie ton quotidien pour manger ton haricot vert!"
[^]Re: Non
Oui, enfin, le c++ est apparu au début des années 80, c'est pas comme une "fourchette 2008"...
Et si pour toi le paradigme orienté objet est un élément délirant issu du marketting de 2008, ton problème ne relève pas de l'informatique.
A moins que tu ne fasse juste le troll au finish...
[^]Re: Non
Va falloir que tu m'expliques où il a critiqué la paradigme orienté objet là... Il a juste critiqué UN langage proposant ce paradigme car le faisant de manière beaucoup plus lourde et complexe que nécessaire...
[^]Re: Non
Merci! (perso j'avais laissé tomber car argumenter avec des gens qui confondent le paradigme objet avec le langage... fatigué moi)
[^]Re: Non
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"...
Tu confonds aussi complexité de la "pile logicielle" et complexité d'un de ses composants.
Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Fatigué tu es, et ça se voit...
[^]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.
[^]Re: Non
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à.
Euh, et à part ça, une argumentation? En dehors de 'cépabien' ?
Non? Pas d'arguments? Faut juste avoir peur des VM et pas se poser de questions?
Tu te dis polytechnicien mais tu semble verser beaucoup dans la superstition.
Et en passant, ce n'est pas la peine de mettre en gras tes propres fautes d'orthographe comme ça :)
[^]Re: Non
> Tu confonds aussi complexité de la "pile logicielle" et complexité d'un de ses composants.
De la même manière qu'une chaine est au moins aussi faible que le plus faible de ses maillons, une pile logicielle est au moins aussi complexe que leplus complexe de ses éléments. C'est pas une analogie fumeuse, juste du bon sens.
> Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Toi par contre, tu confonds concept (le paradigme objet, que personne n'a critiqué ici) et implémentation.(le C++, qui a été effectivement critiqué pour sa complexité monstreuse)
[^]Re: Non
Excepté que le C++ peut être utilisé de façon simple.
Comparaison n'est pas raison.
[^]Re: Non
Ce n'est pas parce qu'il peut être utilisé de façon simple qu'il est simple.
[^]Re: Non
RE
Ouf! Je suis pas tout seul. Mais fait gaffe à ne pas te faire prendre au piège par ces personnes: attention aux threads interminables...
[^]Re: Non
Dans ce cas, j'espère que tu codes sous DOS, parce qu'un noyau d'OS c'est rarement d'une énorme simplicité.
[^]Re: Non
Est-ce que, parce qu'il y a déjà des élements complexes dans la pile logicielle, on peut se permettre d'ouvrir les vannes à tout et n'importe quoi et de rajouter de la complexité à tout va?
[^]Re: Bravo!
Peut-être qu'en fait, le C++ c'est bien.
c'est fini les poissons, on est le 2 avril
[^]Re: Bravo!
Faut dire je n'attendais pas plus de la part des personnes qui ont fait flash.
Adobe n'a fait "que" racheter Macromedia. Ils n'ont pas "fait" Flash.
[^]Re: Bravo!
Hum la belle m... qu'ils nous préparent pour le web!
Je t'aime, dans le genre troll, avis à l'emporte pièce d'une pertinence douteuse, voire qui veulent rien dire, cf. http://linuxfr.org/comments/918824.html#918824 t'es très fort.
Autant dire que ton avis n'engage que toi, en fait.
Exemple con : adobe est bien connu pour flash, qui est d'après toi une merde niveau perfs ? Si effectivement ce sont eux qui sont à l'origine de ces idées, leur avis technique vaut pas tripette, selon toi ?
[^]Re: Bravo!
>Exactement ce qu'il ne fallait pas faire! Une VM pour le web! Cela va apporter son lot d'applications web riches proprios.
La VM dans Gecko2 (Tamarin), est déstinée à exécuter le javascript des pages web. Faudra donc que tu expliques en quoi ça va apporter "son lot d'appli web riches proprio". Du javascript reste du javascript. Ça va pas se transformer en flash ou je ne sais quoi hein. Surtout que bon, pour que la VM puisse executer du flash, il faudrait l'API flash et sa lib derrière, hein, et ça c'est pas du tout au programme.
Et puis si ils ont choisi d'utiliser une VM, c'est bien parce que ça va apporter un plus par rapport à spidermonkey, en terme de perf &cie. Ils ont pas fait ces choix à l'aveuglette pour le bon plaisir d'adobe. D'autant plus que Tamarin a une certaine avancée dans l'implémentation de Javascript 2...
Bon et puis je vois pas ce que viens faire le troll C++ vs C la dedans... Webkit est fait en C++, idem pour Kjs (moteur JS de webkit), et pourtant tu n'en dis rien.
[+] [^]Re: Bravo!
Qui vivra verra...
J'attend le moment où le W3C va normaliser une VM à byte code...
[^]Re: Bravo!
je crois que tu n'as vraiment rien compris aux VM et au projet tamarin.
[^]Re: Bravo!
La VM dans Gecko2 (Tamarin), est déstinée à exécuter le javascript des pages web. Faudra donc que tu expliques en quoi ça va apporter "son lot d'appli web riches proprio". Du javascript reste du javascript. Ça va pas se transformer en flash ou je ne sais quoi hein. Surtout que bon, pour que la VM puisse executer du flash, il faudrait l'API flash et sa lib derrière, hein, et ça c'est pas du tout au programme.
On verra quand le W3C normalisera une VM...
Et puis si ils ont choisi d'utiliser une VM, c'est bien parce que ça va apporter un plus par rapport à spidermonkey, en terme de perf &cie. Ils ont pas fait ces choix à l'aveuglette pour le bon plaisir d'adobe. D'autant plus que Tamarin a une certaine avancée dans l'implémentation de Javascript 2...
L'interpreteur (sans VM) est largement suffisant pour des interfaces graphiques. Et cela nous protège des applications riches web propriétaires bien mieux.
Bon et puis je vois pas ce que viens faire le troll C++ vs C la dedans... Webkit est fait en C++, idem pour Kjs (moteur JS de webkit), et pourtant tu n'en dis rien.
Relis moi: je préfère le spidermonkey de maintenant, pas celui qu'adobe nous prépare.
[^]Re: Bravo!
extrait de : http://www.mozilla.org/projects/tamarin/
The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification. The Tamarin virtual machine will be used by Mozilla within SpiderMonkey, the core JavaScript engine embedded in Firefox®, and other products based on Mozilla technology.
De ce que je vois du projet, la VM, c'est pour avoir une couche intermédiaire, genre :
code jvs <- compilateur de bytecode -> bytecode tamarin <- VM , éventuellement compilation jit -> code natif machine
et pas pour exécuter du bytecode directement.
Sinon pour le reste, je vois pas en quoi ça va faciliter l'arrivée d'appli proprio, qui est déja ultra triviale, genre un plugin flash et roulez jeunesse chez la plupart des gens, un bon vieux gmail ou ce genre d'appli web, une appli proprio de plus qui existe déjà. A toi de faire le tri j'imagine.
[^]Re: Bravo!
Faut dire je n'attendais pas plus de la part des personnes qui ont fait flash
Adobe n'a pas fait Flash, Adobe a racheté la boîte qui l'a fait : Macromedia.
Quitte à cracher sur quelque chose, autant le faire bien...
"L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]
[^]Re: erreur
Pour quand ? Avec quel risque de glissement ?
En attendant ils font quoi ? Rien comme depuis quelques années qu'ils attendent... (parce que bon le rendu html dans gnome et les applis gtk en général...)
Je crois que le fond du problème c'est qu'ils en ont marre d'attendre Gecko, les devs ont envie de s'amuser un peu.
Mais c'est vrai que c'est au moment où mozilla commence à s'en préoccuper que les rats quittent le navire. A moins que Mozilla commence à s'en préoccuper parce qu'ils sentent le vent tourner ?
Et puis si l'usage de gecko se simplifie, il sera sans doute facile d'y revenir.