Downstream developer ver
Downstream developer ver
Posted Apr 3, 2011 19:00 UTC (Sun) by Mook (subscriber, #71173)In reply to: Some clarifications and opinions by kripkenstein
Parent article: Mozilla kills embedding support for Gecko layout engine (The H)
I am a downstream developer.
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
Not at all; there's nothing like the syscall API Linux has. Pretty much any developer doing anything has to end up forking Mozilla, for two reasons: 1) there is no stable API, so downstream is forced to go from one branch to the next (and not stay on mozilla-central) - see, for example, Fennec itself which is going to take the Gecko 2.1 number. 2) You can submit patches all you want, but unless there's a clear benefit to Firefox, you just won't get it in.
For empirical evidence: Songbird, Flock, Netscape 8, Komodo, MicroB (the browser on Nokia Maemo devices) all have patchsets they need to apply.
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.
That has worked out well for a number of things - http://hg.mozilla.org/ipccode/, http://hg.mozilla.org/pyxpcom/, http://hg.mozilla.org/chatzilla/, http://hg.mozilla.org/venkman/. By which I mean, of course, "continually broken because they don't test building them and don't care at all when they break". How's javaxpcom with Eclipse been working out? Unless you happen to actually work on Firefox or Fennec, (or, to a lesser extent, Thunderbird), you are probably not going to keep your code working.
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, to me, shows a lack of understanding of how they work. In case you haven't noticed: all those apps are large enough that getting a first useful version out takes longer than one Firefox version. Coupled with the complete lack of a stable API on the Firefox side, this means if you build them as an extension, you'll only ever be able to release it for the previous version of Firefox. The early adopters needed to get an application off the ground are unlikely to be doing that - would you, today, install an extension that completely changed Firefox into Songbird, if it required you to be using Firefox 3.6 rather than Firefox 4? Songbird is on Gecko 1.9.2.
Sorry, I might be bitter right now because, I quote:
I can appreciate why this is very useful to you guys but it isn't something that we need in the main project right now so all it will represent is added maintenance costs as we do further development
That's just the latest from trying to push changes upstream and watching them rot in bugzilla. If you are starting a new project, I would highly recommend you go use WebKit - at least they don't pretend they are trying to help external contributors.
Posted Apr 3, 2011 20:45 UTC (Sun)
by kripkenstein (guest, #43281)
[Link] (5 responses)
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
> 1) there is no stable API, so downstream is forced to go from one branch to the next (and not stay on mozilla-central) - see, for example, Fennec itself which is going to take the Gecko 2.1 number.
Not sure what you mean about Fennec here - I'm a Fennec dev, and we track mozilla-central very closely. We use the same mozilla-central for our releases as desktop (perhaps a few commits earlier or later though). Point updates might end up a little different, but overall, we use mozilla-central just like desktop Firefox does.
> 2) You can submit patches all you want, but unless there's a clear benefit to Firefox, you just won't get it in.
I agree with this point and I'm concerned about it. We need to improve about that.
> That, to me, shows a lack of understanding of how they work. In case you haven't noticed: all those apps are large enough that getting a first useful version out takes longer than one Firefox version.
I would argue here, that they take so long *because* they fork the browser. If instead things like RockMelt started out as a Firefox addon, they could be finished much earlier. Yes, as you say they would need to keep up to date with new Firefox versions, but the benefits of that outweight the disadvantages.
The primary reason Flock and RockMelt are browsers, and not browser plugins, *is not technical*. The main reason is financial: Their business model is (or, for Flock, was) in large part identical to Firefox's: Revenue sharing with search engines. Only the browser itself participates with that, not addons, so they are forced to release entire browsers, with all the technical burden that that brings.
> Sorry, I might be bitter right now because, I quote: "I can appreciate why this is very useful to you guys but it isn't something that we need in the main project right now so all it will represent is added maintenance costs as we do further development"
Reading that makes me unhappy too. As I said above, I agree that we need to improve with that stuff. Can you please link me to the quote's source, so I can see the whole picture and try to help?
Posted Apr 3, 2011 23:47 UTC (Sun)
by jrn (subscriber, #64214)
[Link] (3 responses)
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.
Posted Apr 4, 2011 0:01 UTC (Mon)
by kripkenstein (guest, #43281)
[Link] (2 responses)
>> "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.
Posted Apr 4, 2011 1:13 UTC (Mon)
by Mook (subscriber, #71173)
[Link] (1 responses)
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).
Posted Apr 4, 2011 1:39 UTC (Mon)
by kripkenstein (guest, #43281)
[Link]
> 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.
Posted Apr 4, 2011 0:13 UTC (Mon)
by Mook (subscriber, #71173)
[Link]
Sure, and that's why nobody has had a successful run at developing drivers out-of-tree other than perhaps nVidia (with their _own_ stable API layer). People who develop on top of Mozilla can't just use some limited subset of API, because they're not developing device drivers that only ever need to talk to one thing.
> Not sure what you mean about Fennec here - I'm a Fennec dev, and we track mozilla-central very closely. We use the same mozilla-central for our releases as desktop (perhaps a few commits earlier or later though). Point updates might end up a little different, but overall, we use mozilla-central just like desktop Firefox does.
Firefox (desktop) always releases on a branch. Fennec, last I checked (I may be wrong!) was going to release off 2.1. I was going by http://oduinn.com/blog/2011/03/09/branch-mechanics-for-fi... which was what I last saw on planet.m.o. Fennec also gets the advantage here of actually being on a tinderbox people (vaguely) care about when they checkin.
> I would argue here, that they take so long *because* they fork the browser. If instead things like RockMelt started out as a Firefox addon, they could be finished much earlier. Yes, as you say they would need to keep up to date with new Firefox versions, but the benefits of that outweight the disadvantages.
No, you can't sensibly build a product (or a house) with a shifting foundation. Let's pretend they started at Firefox 4 beta 1 (roughly 9 months ago). They would have been bitten by UI changes such as the total revamp of the status bar, the randomly-reset toolbars, the whole Firefox button deal, the on-again-off-again web console. With the sort of UI changes they want that don't sound fun. And that's just the major frontend changes, not including things like the repeated JS engine changes that - while making Firefox faster - kept adding limitations that Firefox happened to not care about.
> The primary reason Flock and RockMelt are browsers, and not browser plugins, *is not technical*. The main reason is financial: Their business model is (or, for Flock, was) in large part identical to Firefox's: Revenue sharing with search engines. Only the browser itself participates with that, not addons, so they are forced to release entire browsers, with all the technical burden that that brings.
I would agree that that's probably a large reason, yes. But imagine they were doing this an extension. Your app will now completely not work on timelines you have no control over (when a new Firefox is released), with no way to even tell the user that might be bad. If you tried to prevent the app from updating, you can bet you are going to get blocklisted (regardless of whether you distribute on addons.mozilla.org, the blocklist affects everybody - it's the same mechanism they use to block malware). When things break for you, you can't change the code to suit you, because you don't ship it, and if you submit patches, they languish until after the next Firefox release is out because it's not a blocker for Firefox.
> Reading that makes me unhappy too. As I said above, I agree that we need to improve with that stuff. Can you please link me to the quote's source, so I can see the whole picture and try to help?
Ping me on IRC? I'm dumb enough to use the same name. The guy saying that has historically been nice with external developers, but like everyone he needs to meet timelines so things like reviewing patches without considering what app it's for isn't going to happen without an organizational change.
Downstream developer ver
Downstream developer ver
Downstream developer ver
Downstream developer ver
Downstream developer ver
Downstream developer ver