Quiconque a suivi les actualités récentes au sujet de Firefox sait que le navigateur va subir cette année de profondes transformations. Cela tient aussi bien à son code qu’à la manière dont Mozilla se charge de son développement. Pour continuer dans cette voie, l’éditeur prend des décisions plus radicales en ce qui concerne la reprise des composants de Firefox dans d’autres projets, en particulier le moteur de rendu.
C’est l’ingénieur Benjamin Smedberg qui l’explique dans un post sur un groupe de discussion. Il y explique que la réflexion a porté sur plusieurs composants gardés pour des questions de compatibilité mais qui empêchent maintenant les développeurs d’avancer au rythme qu’ils voudraient. Est concerné également le moteur de rendu, repris dans d’autres projets communautaires, tels que Camino, un navigateur dédié à Mac OS X.
Sont donc touchés les composants gktmozembed, javaxpcom, le contrôle et le plug-in ActiveX ainsi que le code IDispatch. Le moteur de rendu Gecko lui-même va souffrir d’une baisse très conséquente des effets faits pour le rendre manipulable par d’autres projets, notamment parce qu’il va subir de grandes transformations prochainement, surtout à cause de la mise en place du projet Electrolysis. Pour rappel, ce dernier va permettre de rendre le moteur multiprocessus, avec deux objectifs majeurs :
À noter que l’ingénieur invite tous ceux concernés par ce sujet à entrer en contact avec lui pour définir la meilleure méthode dans le cas où certains seraient intéressés par la future solution multiprocessus de Gecko.
C’est l’ingénieur Benjamin Smedberg qui l’explique dans un post sur un groupe de discussion. Il y explique que la réflexion a porté sur plusieurs composants gardés pour des questions de compatibilité mais qui empêchent maintenant les développeurs d’avancer au rythme qu’ils voudraient. Est concerné également le moteur de rendu, repris dans d’autres projets communautaires, tels que Camino, un navigateur dédié à Mac OS X.
Sont donc touchés les composants gktmozembed, javaxpcom, le contrôle et le plug-in ActiveX ainsi que le code IDispatch. Le moteur de rendu Gecko lui-même va souffrir d’une baisse très conséquente des effets faits pour le rendre manipulable par d’autres projets, notamment parce qu’il va subir de grandes transformations prochainement, surtout à cause de la mise en place du projet Electrolysis. Pour rappel, ce dernier va permettre de rendre le moteur multiprocessus, avec deux objectifs majeurs :
- Séparer le navigateur proprement dit de son moteur de rendu
- Permettre à chaque page web de se charger dans une instance séparée de Gecko, pour isoler les onglets les uns des autres, à la manière d’Internet Explorer et de Chrome
À noter que l’ingénieur invite tous ceux concernés par ce sujet à entrer en contact avec lui pour définir la meilleure méthode dans le cas où certains seraient intéressés par la future solution multiprocessus de Gecko.
