| |||||||||||||
Downstream developer verDownstream developer verPosted Apr 3, 2011 23:47 UTC (Sun) by jrn (subscriber, #64214)In reply to: Downstream developer ver by kripkenstein Parent article: Mozilla kills embedding support for Gecko layout engine (The H)
> Sorry if I wasn't clear, what I meant was more in regards to people developing device drivers for Linux. There isn't a stable API for that, http://www.kroah.com/log/linux/stable_api_nonsense.html
There are some (stable) APIs for developing device drivers in userspace. But you have not mentioned the main point of that document, which is that (at least according to Greg) an out-of-tree device driver in kernel space is a Bad Idea.
Is the same true for gecko embedders? Is it fair to declare that any (say) help browser ought to be developed in the mozilla tree and that the mozilla team will help maintain it? If so, then you would have a good analogy.
(Log in to post comments)
Downstream developer ver Posted Apr 4, 2011 0:01 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
I guess I presented my point poorly: I don't think that Mozilla is a *perfect* parallel to Linux, just that there is a major similarity here. Specifically, the aspect I meant is summarized very well by gkh in that link, which is why I provided it:
>> "Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly."
Similarly, Mozilla is moving forward very fast, and a fixed, stable embedding API would slow that down. The proper solution, I personally think, is (1) Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this). This obviously means they need to keep up to date if they are out of tree, or that they should be in-tree (in the mozilla-central repo). And the other part of the solution is (2) to provide a very simple, very stable, very high-level API, *not* for embedding, but for Firefox (and other browsers) to provide rendering services for other apps (on Linux, using DBUS). It should be just a few lines of, say, Python, to get a rendered page given a URL, with the browser doing all the work.
Downstream developer ver Posted Apr 4, 2011 1:13 UTC (Mon) by Mook (guest, #71173) [Link]
> Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this).
Songbird certainly doesn't; I doubt Fennec does, either. The whole not being part of libxul thing and all.
> This obviously means they need to keep up to date if they are out of tree, or that they should be in-tree (in the mozilla-central repo).
Except that people are _against_ putting more things in m-c - see pyxpcom, for example, which used to be in-tree before hg, or ipccode which isn't either.
> (2) to provide a very simple, very stable, very high-level API, *not* for embedding
But what people _want_ is embedding, because they want to be able to control the browser - where it navigates to, when it tries to launch the system browser instead for off-site links, what context menu gets shown. Just slamming a remoted Firefox bitmap in doesn't provide enough controls. At this point, of course, any new projects would be better off using WebKit (via Gtk/Qt/Cocoa bindings) or IE (IWebBrowser).
Downstream developer ver Posted Apr 4, 2011 1:39 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
>> Apps that use the Gecko platform, use it directly, using internal APIs (apps like Fennec and Songbird already do this).
> Songbird certainly doesn't; I doubt Fennec does, either. The whole not being part of libxul thing and all.
For Songbird I am just relaying what I was told - I guess that is incorrect then. I am a Fennec developer though: We definitely use the internal Gecko APIs, in fact we use them exactly as Firefox does.
My point is that it would be very feasible to write something like Camino in the same way as we write Fennec: use the Gecko platform, add a completely new UI on top of that.
> Except that people are _against_ putting more things in m-c - see pyxpcom, for example, which used to be in-tree before hg, or ipccode which isn't either.
It really depends on what.
Regarding pyxpcom specifically, I am not sure, but I seem to recall the issue was that it lacked a maintainer?
> But what people _want_ is embedding, because they want to be able to control the browser
There are lots of different use cases here. I agree my suggestions don't cover them all. I do think though that they would cover most of them, but that is of course debatable.
|
|||||||||||||