een beetje onduidelijk bericht, ergens anders las ik dit:
I'm a developer at Mozilla. It looks like there is some confusion about this announcement.
1. Most importantly, *it is still possible to create applications that use Gecko*. Even without the Gecko embedding APIs, you can write such apps. For example, there are two separate Mozilla-supported apps that use Gecko: Firefox and Fennec (mobile Firefox). There is also Songbird, which is written in a similar way (the article mistakenly implies Songbird will be negatively affected by this announcement, which is not true - the situation for them is very different than for Camino, for example).
In other words, you *can* still write Gecko apps, but you must integrate tightly with Gecko. This is sort of like the Linux kernel not committing to a stable API, things change as needed (people sometimes complain about that, but overall it lets the kernel move forward faster). Similarly, for Mozilla moving forward is much easier without committing to stable APIs for embedding. But again, you can still write apps that use Gecko without such APIs, just like you can write code for Linux.
2. Second, to clarify the term 'killed' that the article used: If someone steps up to maintain the embedding APIs, they can continue. So in that sense nothing is 'killed'. It is just that Mozilla itself, however, isn't focusing on them, for the reasons I mentioned before.
So, where does this leave things? If you want to write an app that embeds an HTML engine, you can still choose Gecko or WebKit. WebKit is easier to embed, but that has a price. As an example, look how quickly Google added cross-process support to Chrome, without any stable API promises and without anything but Chrome benefiting; Apple is adding cross-process support to WebKit itself, with a stable API, but it is still not complete as the process takes much longer.
I would argue, however, and this is totally my personal opinion - not Mozilla's - that all of this *doesn't really matter*. The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa. What I am trying to say, is that these days people fire up their web browser and do everything from read news to check email to play games. They don't have separate apps for each that embed a web browser, they have a single web browser for all their activities.
Current applications that embed web browsers, like say Songbird, could today be websites or browser plugins, as browser capabilities have improved so much recently. For that matter, alternative browsers like Flock and RockMelt could be browser plugins.
That leaves projects like Camino and Epiphany that provide much better OS integration than cross-platform browsers like Firefox or Chrome. There is a place for such OS integration. Some of it can be achieved with browser plugins, but I concede that it might be necessary in some cases to do more. I think that such work code be done with the upstream projects, though, to get the best results, as opposed to separate projects that just embed rendering engines. For example, Firefox can render using Qt on Linux, but it needs more love - would be great to see more Qt hackers contribute upstream on that, and to get Firefox/Qt stable.
Apple
