(As in, "From the Earth To The Moon".)
So the Mozpad group has started, even though we don't have all our goals figured out yet. I think overall the group has gotten a pretty good response, much like SeaMonkey did when they first started out. But we're not out of the woods yet.
With the creation of moon.mozpad.org, I'm going to need a bit of help creating a RSS feed for them. I'll be creating a new category on my blog, "XULRunner thoughts", but unfortunately, I don't know enough about MovableType to create a feed template for a category. So if anyone out there can lend a hand (or better yet, some markup template with instructions on where to put it), I'd appreciate it. Other MZ-hosted bloggers might like it too.
One of the proposed goals for Mozpad is to figure out some basic requirements for a successful XUL IDE project. (No, we're not committing to building the IDE yet. That is a Really Hard Problem.) So when we do get a Mozpad newsgroup, I'll be starting a newsgroup thread to ask what the community thinks they need. (Please don't post replies to this blog entry; I just want to start people thinking about it.) Even so, we're going to need a leader to gather the feedback and process it into a coherent requirements specification. No one's stepped forward to champion that goal yet, and understandably.
I think, realistically, our goals for Mozpad are -- and should be -- shorter-term ones - somewhere around six months. Longer-term goals we do not want to set for ourselves, as we're just starting out. We need to crawl before we learn how to walk, as the old saying goes. Everything on the goals list is achievable with a little effort, and would net the community-at-large some tangible, healthy benefits. So if you can spend a couple hours a week on one of these subjects and it interests you, we could use your help as a champion, as a leader.
Finally, I'll continue to put all my posts through planet.mozilla.org, even though the XULRunner-specific posts will also be on Mozpad. It's just another step on the way to Florida, with a really BFG, pointed at the moon. Cover your ears, folks, it's going to be a doozie.
How many times do you see code like this:
var factory = {
createInstance: function createInstance(outer, iid) {
// ...
if (outer != null) {
throw Components.results.NS_ERROR_NO_AGGREGATION;
}
return (new FooComponent()).QueryInterface(iid);
}
};
var Module = {
registerSelf: function registerSelf(compMgr, fileSpec, location, type) {
// ...
},
getClassObject: function getClassObject(compMgr, aCID, aIID) {
// ...
},
// ...
}
It's everywhere in Firefox and XULRunner-based applications. But not for long...
Robert Sayre resurrected bug 238324, which implements a JavaScript code sharing system. This means common code which gets repeated ad nauseum (and risks bugs from duplication) can be reduced to a much smaller boilerplate. Fifty to sixty lines of JS reduce to fifteen:
Components.utils.import("rel:XPCOMUtils.jsm");
var NSGetModule = XPCOMUtils.generateNSGetModule([
{
className: BarComponent.prototype.classDescription,
cid: BarComponent.prototype.classID,
contractID: BarComponent.prototype.contractID,
factory: XPCOMUtils.generateFactory(
function barCtor() {
return new BarComponent();
},
[Components.interfaces.nsIClassInfo]
)
}
], null, null);
By the way, the above code also means you don't have to implement QueryInterface() either. (Yes, you do - classinfo interface flattening doesn't work without it, and many others will be broken. Oops.) Expect much code bloat reduction from this in Gecko 1.9, including Firefox and Thunderbird.
This is just the tip of the iceberg. I find myself writing a lot of boilerplate JS code for enumerators, and a bit of arrays. Maybe we can eliminate that, too. Or perhaps other shortcuts for implementing nsIClassInfo or other interfaces. With XUL/JavaScript preprocessing, maybe I could even contribute my design-by-contract library to mozilla.org now - though that could mean preprocessing a lot of component files too. I'm not sure we want to do that.
Sure, all the above could be done via the JavaScript subscript loader, and in fact, that's how the common code gets imported. That route is slow, though. Now it's standardized through C++.
If you can come up with other frequently repeated code, file bugs for code redux under Core -> XPConnect and dependent on bug 238324. Feel free to cc me too; I'll be very happy to implement it, if someone else doesn't beat me to it!
I promised shaver that I would retract my words if I had misinterpreted XULRunner 1.9 executables being unavailable. Today, I gladly do so, as bsmedberg indicates yes, they will be available:
Make sure that prepackaged XULRunner builds are available.
That's all I was asking for. Now we just need better docs (something we've been complaining about long before we complained about a GRE... ;-) ) Would someone please pass the salt?
My apologies to everyone for flying off the deep end earlier.
I've noticed a recurring theme here: those who say we can't put out a XULRunner 1.9 are saying it's because we need system-level integration: one XULRunner instance supporting several applications on the same machine at the same time, I think. This is the JRE runtime model I've seen a couple people throw around.
I want to throw out a radical idea: what if we simply dropped that requirement for 1.9?
Simply put, I think it's a nice-to-have convenience, but I as an application developer do not need it. If that's the primary point of contention preventing a XULRunner build being blessed as 1.9, maybe we can have our cake and eat it too.
Perhaps we simply need to ask a better question: What does the community need, and what can they live without?
For the last several days, I have been watching the discussion about Firefox versus XULRunner with some amusement, and without making any blog posts of my own. That stopped today with Mitchell Baker's official policy statement. As Chief Lizard Wrangler, she does have the authority to do this.
I also want to state that I understand the rationale for the decision, and from the Mozilla Foundation's point of view, the decision is entirely sensible. I don't like it, but I accept it.
(For the record, I'm going to refrain from making more posts about the discussion unless I have something of value to say, something which will offer proposals or solutions. Several others who have blogged about it have merely been complaining or expressing their opinion. I don't see that as productive - even less so now that Mitchell's made her call. I would encourage my fellow platform enthusiasts to propose improvements now to benefit the community, and to work with the Mozilla Foundation in every way possible. We don't need any more acrimony over this subject.)
The significant part of her statement, for me, is this:
The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2.
My response to that? OUCH.
Seriously, this hurts. A lot. With that one statement, the burden on me as an application developer, long-term, has just gone up. Verbosio development has proceeded on the assumption -- reflected in the original XULRunner roadmap -- that there would be an official XULRunner 1.9 platform release. Now, like everyone else, I'll be forced to build executables, or telling users to build their own off some GECKO_1_9_RELEASE source tag. What makes this particularly painful is I do not have the resources of a corporate organization - no QA, no docs people, nothing.
It also lowers the priority on other platform-specific bugs to "ehh, we'll get to it someday." Bugs for things like toolkit extensions. Want Venkman or Firebug in your app? Build it yourself! You're a developer, you can do it. And if we ever update those in our source, build it yourself again. This is part and parcel of software development. Deal with it.
Which leads me to my next thoughts: damage control. MoCo's made their decision. Fine. That's their right, and I strongly suggest that anyone trying to fight it is helping entropy. (Consult Diane Duane's "Support Your Local Wizard" series for an explanation why this is a Bad Thing.) I'm not happy with the decision, but it's been made.
Recently the AllPeers blog suggested an official Mozilla Platform User Group (Mozpad). I think this is a fine alternative, and given the opportunity, I would participate heavily in such a group. If a community arises to produce and support XULRunner 1.9 builds, fantastic. We would probably have to create our own Addons service akin to AMO - if MoCo won't support XR 1.9, why support XR 1.9 extensions? - but I would resist forking XR 1.9 code itself in even the tiniest detail unless it became absolutely necessary.
There's also another thought I want to express: what's going to happen with the current 1.x series of code after Firefox 3?
It's generally accepted work on Mozilla 2 will begin in earnest after Fx3's release. Wonderful. Of course, nobody knows how long it will be until Mozilla 2 is remotely usable or stable enough for dogfood development. This presents a problem which I've talked about on IRC, but has not been mentioned on any weblog or in any official capacity.
Suppose Mozilla 2 takes a long, long time. 18 months is a long time in software development, and of course there's no release date set in stone for that either. Mozilla 2 is the future, but I wouldn't bet on anybody keeping to any posted deadline for it. Mozilla 1.0 took a lot longer than anyone thought it would, remember.
So what happens with the 1.x trunk line of code on CVS? (I have no reason to doubt there will be security & maintenance of the 1.9 branch - MoCo would be fools not to do that.) No one's talked about that, and I think it's time someone did in an official manner. Any number of things could happen:
This last option appeals to me most, particularly in light of the above XULRunner apps discussion. Think Apache 1.x versus Apache 2.x. Both are still out there, even though Apache 2 has long since superseded Apache 1.
The simplest solution to everything I've talked about in this article might be that a XULRunner community adopts the 1.x trunk for a theoretical 1.10+ code base. This has a bit of elegance to me, in that the XR community could do whatever they wanted to 1.10 code, and check in changes which benefit the community in the short term while we wait for Mozilla 2. The community could then use some odd product name ("Genesis", "Foundation", "Ringworld", "Protomatter", etc.) for their own project. (I like "Protomatter", myself.)
I think I'll end this editorial with one last thought reiterating something I said earlier. Please don't take my blog as a venue for complaining about XR 1.9 being vaporware. I'm not interested in that. XULRunner app builders now perceive a problem, and whether or not that problem is real, the worst thing we XR users can do is complain about it. The best thing we can do is start a discussion about "What do we do now?". That's what I want this blog entry to be about, and that's what comments I will approve on this entry. If you want to gripe about it without offering a solution, do it on your own blogs. :-)
One of my "favorite" phrases in working on bugs is "reduced testcase". It's not always easy to do that, though, and I'm starting to think about ways to do that. I'm posting this now to get some feedback.
Please read the extended entry for details (it's a bit technical).
In Verbosio right now there's a strange cross-platform layout bug. I've got an iframe with a yellow background on top of another iframe. Windows shows the yellow background; Linux and Mac don't. This sounds like a good need for a layout reftest. Unfortunately, to get to the strange bustage, you have to go through about five steps. Reducing that to a simple reftest does not sound easy.
I'm personally thinking we could do something about that:
That's a long-winded way of saying "Record, reduce, generate a comparison document, save."
For building a xpcshell-based testcase and reducing it, there might be other possibilities. Shane Caraveo's Casper record/replay harness could be a starting point, along with Venkman for tracing:
In short, this means "Record, reduce, save." Not too different from the procedure I suggest for a layout reftest generator tool.
I tried pitching the above xpcshell test idea to Silver several weeks ago, but I don't think I was very clear then. I'm not even sure I'm clear now. Also, for Verbosio, I can't use xpcshell on my custom components because they're not native to XULRunner (see bug 359830 for details). But I have a test engine component which does basically the same thing.
Please let me know what you think. Are tools like this feasible? Do you have better ideas for implementing them? Can you think of similar tool designs for reducing testcases? Are you willing to write tools like these?
Well, why not?
I've been thinking for a while that Verbosio could bring a lot to the table if you could use it to work on Firefox extensions. Fundamentally, it would be trivial to add support for that to Verbosio.
Verbosio is a XUL application I'm building for editing XML. That's its fundamental goal. For the 0.1 release, Verbosio's first requirement is the ability to reliably edit Verbosio. That means Verbosio needs to understand XUL, XBL, a little JS and a little CSS, DTD... all things that you need for a Firefox extension editor too.
I really do think I could add support for Firefox extension development in a day. It'd be as simple as creating a single component implementing xeIDocumentPack. That same component would mean support for editing Thunderbird extensions, NVu extensions, Sunbird extensions, Songbird extensions, Flock extensions... you name it, if it's a XUL-based application extension, Verbosio could probably start editing it with that single component.
So I'm thinking I should add a second requirement to Verbosio 0.1: "Verbosio should be able to edit Firefox extensions reliably." With that one requirement met, Verbosio would be significantly more useful to the Mozilla community at large, and it would invite people to look at Verbosio more. That might be enough eyeballs to make my bugs shallow.
UPDATE: Done! Now you can open extensions in Verbosio for editing.
How would you build it?
Over the next few decades, the United States of America has expressed an intent to place a man on Mars. While it does have its coolness factor (akin to landing on Luna, our moon, in 1969) and an enormous price tag, it leaves a number of questions. For example, how do we protect (and for that matter, define) the health of the astro/cosmo/taiko-nauts? What equipment should we take (i.e. what we would do there)? Should we leave room for cargo - bringing Mars rocks back with us? A question that interests me, though, is how we would keep in touch with the fourth planet, particularly with something more than just radio and digital pictures.
More thoughts in the extended entry.
Nowadays, we take for granted that we can send an e-mail with an attachment to someone we're chatting with, real-time, and they can see the attachment almost instantaneously. We take for granted that we can fetch a webpage and see it in seconds. We take for granted that if there's ever a problem, we can at least talk to the people who can fix the problem right away.
The laws of physics as we understand them now tell us we can't take that for granted between planets - or even between Earth and Luna. Any physicist, and for that matter most amateur radio operators (like me), will tell you there's a time delay you can't beat right now: the speed of light. Even to the Moon and back, there's a measurable delay in a transmitted signal. From here to Mars, well... hours.
Existing browsers can't really function that way, at least not directly. When you request a HTML page, your browser gets the source code behind the page, and then discovers it has to fetch four JavaScripts, two stylesheets, and twenty images. The stylesheets want thirty more images. All these requests traveling back and forth over the light-minutes of space would be a horrible user interface for the people using it.
In a situation like this, the best answer I can come up with would be a special proxy on Earth. The proxy receives a request from Mars, and acts on it to get all the requested documents. Then it packages them up and sends them in one big burst to the recipient. Both the client and the proxy would have to be based on a similar platform, so the client really gets what they expect.
Even this way, it might be horribly slow. You might as well find out ahead of time what interests the people on a mission to Mars, and send an intranet server with them - which would pre-fetch pages they're most likely to look at. That way, they wouldn't have to wait as long... (I don't want to get into discussions of who would provide the Internet content to the travelers - especially since that leads into questions of monitoring the content and privacy.)
There's also the "kiddie" factor - imagine a webcast from Mars to students in a classroom on Earth. The kids would have to send their questions on one day, and wait until the next for any response. Then if they wanted to ask more questions, that's another day.
For me as a Mozilla developer, if I were ever fortunate enough to go to Mars, I'd want to set up a special mirror of the current Mozilla trunk, which gets synchronized daily or weekly. Even a simple CVS or SVN query - or Hg, or Bazaar, etc. etc., might need customization to work with such long distances. On the other hand, because carbon-based life forms are the biggest speed limit in software development, the pace of patch reviews would not change appreciably. :-)
Seriously, even on the journey to Mars, the crew would need something to do besides fly their ship and maintain their scientific equipment. I break the tension myself by reading - and occasionally writing - science fiction. Twenty years from now, we'll be so adapted to having data at our fingertips instantly that to drop back to "we'll get that to you in a few hours" will feel like we've slipped back a century. Having some semblance of the Internet "out there" might help a bit.
Put another way, the Spirit and Opportunity rovers send us back pictures. I personally don't know if they send video or not. But in any case, human beings will need a lot more bandwidth than a dinky little remote-controlled robot...
That's my opinion. What do you think?
A few days ago, I took my Windows desktop into the shop again - this time to pull the second hard drive (which had always been dedicated to Linux) and stick it into a new Linux computer. Dual-boot with Fedora Core didn't work, and I'd never really used the Kanotix install on the second drive anyway, so I figured I just needed a new box.
So I've got it, and I'm rather pleased. Now I've got platform coverage on all three major Mozilla platforms for the trunk, and I don't have to do any great acrobatics.
One small problem though: two desktops, two monitors, three keyboards, three mice, a Mac Mini, a MacBook, a router, and a cable modem take up an awful lot of space. I bought this cheap flat table from Office Depot a couple years ago, and now it's pretty full. I've never known anyone to really make a computer desk especially for multiple computers... and I need one. :-)
Oh, and Verbosio looks pretty good - but not perfect - on Fedora Core 6. Screenshots forthcoming... when I have something new to show.
UPDATE: A lot of people have replied saying, "Why don't you try a KVM?" The answer is I have tried it before when I bought the Mac Mini. The picture degradation made it an instant bust.
Synergy I haven't heard of, and I will take a look.