"Ich dachte du spielst auf eine gemeinsame Nutzung der selben Bibliotheken an."
So in etwa dachte ich mir das.
Unter Debian hängt Iceweasel von Xulrunner (Debian spricht in diesem Zusammenhang von einer "single gecko runtime" mit integrierter libxul) ab, Icedove benutzt diese shared library leider nicht, da er eine Art "embedded Xulrunner" mitbringt.
Wenn die in Debian integrierten Versionen von Iceweasel und Icedove den gleichen Xulrunner benutzen könnten, dann wäre es unsinnig, dass Thunderbird/Icedove genau das prinzipiell nicht macht.
Das wäre auch ideal in punkto Sicherheitsupdates, da praktisch alle Sicherheitslücken in Xulrunner-1.9 anfallen, weshalb es meist in Iceweasel nichts zu fixen gibt. Bei Icedove sieht das zur Zeit anders aus und macht nur unnötig Arbeit. Mit Epiphany-Gecko ist das z.B. möglich, da Epiphany in Lenny ebenfalls Xulrunner-1.9 benutzt, genauso wie übrigens Galeon. Meistens muß man also nur Xulrunner-1.9 fixen und braucht an Epiphany, Galeon und Iceweasel nicht mehr herumzupatchen.
In Lenny hätte das allerdings mit Icedove leider so und so nicht funktioniert, da Icedove 2.0.0.x einen Xulrunner 1.8 ("Gecko 1.8.1") und Iceweasel 3.0.x ("Gecko 1.9") einen Xulrunner 1.9 benötigt.
Bei Debian könnte das sogar hinhauen, da die ja kleine Forks haben, aber grundsätzlich gehört TB nicht mehr zu Mozilla sondern wurde irgendwie ausgelagert. Die beiden Projekte müssten sich aber absprechen und zeitgleich Updates mit gleichem XUL-Runner bzw. gleicher Gecko-Engine rausbringen. Das wird nie was. Unter Windows (und Mac OS x wohl auch) sowieso nicht, da die beiden Anwendungen die Updates für sich selbst holen, es bräuchte da aber einen Prozess der beide gleichzeitig aktualisiert. Wahrscheinlich haben die Entwickler da auch kein all zu großes Interesse dran.
Die Entwicklung von Thunderbird wurde nur an eine eigen Firma übergeben, die aber genau so wie die Mozilla Corp der Mozilla Foundation gehört.
Um beide oder mehrere Produkte mit der selben XUL Basis zu bedienen, müsste diese Technologie praktisch eigene Releases machen, z.B. als von der Mutterstiftung veröffentlichtes Produkt.
Was Windows und vermutlich auch OS X betrifft, ist es natürlich richtig, dass dort das Bereitstellen von Frameworks schwieriger ist und daher oft nicht gemacht wird. Ich kenne das jetzt nur von Anwendungen, die die Java oder .NET Runtime benutzen und im Laufe ihres eigentlichen Installationsvorgangs den Installer der Runtime ausführen, falls das nötig sein sollte.
Aber ich denke das Hauptproblem im Falle von Gecko ist, dass es nicht als alleine stehendes Produkt veröffentlicht wird und daher die meisten benutzenden Projekte mit einer Kopie einer bestimmten Version arbeiten.
"Ich dachte du spielst auf eine gemeinsame Nutzung der selben Bibliotheken an."
So in etwa dachte ich mir das.
Unter Debian hängt Iceweasel von Xulrunner (Debian spricht in diesem Zusammenhang von einer "single gecko runtime" mit integrierter libxul) ab, Icedove benutzt diese shared library leider nicht, da er eine Art "embedded Xulrunner" mitbringt.
Wenn die in Debian integrierten Versionen von Iceweasel und Icedove den gleichen Xulrunner benutzen könnten, dann wäre es unsinnig, dass Thunderbird/Icedove genau das prinzipiell nicht macht.
Das wäre auch ideal in punkto Sicherheitsupdates, da praktisch alle Sicherheitslücken in Xulrunner-1.9 anfallen, weshalb es meist in Iceweasel nichts zu fixen gibt. Bei Icedove sieht das zur Zeit anders aus und macht nur unnötig Arbeit.
Mit Epiphany-Gecko ist das z.B. möglich, da Epiphany in Lenny ebenfalls Xulrunner-1.9 benutzt, genauso wie übrigens Galeon. Meistens muß man also nur Xulrunner-1.9 fixen und braucht an Epiphany, Galeon und Iceweasel nicht mehr herumzupatchen.
In Lenny hätte das allerdings mit Icedove leider so und so nicht funktioniert, da Icedove 2.0.0.x einen Xulrunner 1.8 ("Gecko 1.8.1") und Iceweasel 3.0.x ("Gecko 1.9") einen Xulrunner 1.9 benötigt.
Bei Debian könnte das sogar hinhauen, da die ja kleine Forks haben, aber grundsätzlich gehört TB nicht mehr zu Mozilla sondern wurde irgendwie ausgelagert. Die beiden Projekte müssten sich aber absprechen und zeitgleich Updates mit gleichem XUL-Runner bzw. gleicher Gecko-Engine rausbringen.
Das wird nie was. Unter Windows (und Mac OS x wohl auch) sowieso nicht, da die beiden Anwendungen die Updates für sich selbst holen, es bräuchte da aber einen Prozess der beide gleichzeitig aktualisiert. Wahrscheinlich haben die Entwickler da auch kein all zu großes Interesse dran.
Die Entwicklung von Thunderbird wurde nur an eine eigen Firma übergeben, die aber genau so wie die Mozilla Corp der Mozilla Foundation gehört.
Um beide oder mehrere Produkte mit der selben XUL Basis zu bedienen, müsste diese Technologie praktisch eigene Releases machen, z.B. als von der Mutterstiftung veröffentlichtes Produkt.
Was Windows und vermutlich auch OS X betrifft, ist es natürlich richtig, dass dort das Bereitstellen von Frameworks schwieriger ist und daher oft nicht gemacht wird.
Ich kenne das jetzt nur von Anwendungen, die die Java oder .NET Runtime benutzen und im Laufe ihres eigentlichen Installationsvorgangs den Installer der Runtime ausführen, falls das nötig sein sollte.
Aber ich denke das Hauptproblem im Falle von Gecko ist, dass es nicht als alleine stehendes Produkt veröffentlicht wird und daher die meisten benutzenden Projekte mit einer Kopie einer bestimmten Version arbeiten.