I’ve come out of the closet recently as a big fan of WebRunner, so it was incredibly exciting to see Mozilla officially take the project under its wing with a great new name and branding. As far as I’m concerned, this is where the future’s at.
Since I’m all about putting my money where my mouth is, this raises the intriguing question of what it would mean to port a complex extension like AllPeers to Prism. We’ve certainly got a lot of mileage out of AllPeers as an extension, leveraging the full functionality of Firefox including the relatively easy extension installation process. Nonetheless, the need for explicit downloading and installation of a lot of code (mostly compiled C++) is a drag. Turning AllPeers into a true web app would remove all of the remaining friction for potential adopters.
The first question is how much existing functionality could be rewritten in JavaScript. Clearly JavaScript 2 will ease this task since it brings a lot of new programming constructs to the party that simplify the implementation of complex application logic. Tamarin is also a virtual must since its just-in-time compilation will have a major impact on performance. It should theoretically be possible to implement our entire resource management framework and networking layer in JS (although this would be painful since it implies rewriting a lot of existing code). I’m pretty sure some additional low-level networking code would have to be exposed by Mozilla, since we make extensive use of NSS directly.
The only remaining essential binary code in AllPeers is our codec support: we embed both FreeImage and the FFmpeg libraries in order to extract metadata from media files (height, width, length, bitrate, etc.) and generate thumbnails. With the work that Stuart Parmenter has done on Mozilla’s support for image encoding/decoding and the planned video and audio tags, it isn’t too much of a stretch to imagine a future Firefox where codecs can be installed in a manner similar to plugins and made available to JavaScript code. (Mike Shaver touched on this during his talk on future browser features at Mozilla 24.)
We also need some way to store our data in an efficient local database. Something like Google Gears would presumably fit the bill. It doesn’t look to me like DOMStorage will scale for a large repository of highly structured data, but I might be mistaken about that. I’m not sure how much traction (if any) Google Gears has outside of Google itself, but if it doesn’t catch on then some other persistent storage mechanism will be needed that gives applications control over the database at the SQL level.
The other issue that springs to mind is how to overlay AllPeers-as-a-web-app onto Firefox. We’ve had many people express interest in running AllPeers in a separate process, but a lot of the product’s appeal, in my opinion, stems from the fact that it is right there in your browser when you need it. This means that web apps need to be able to modify browser chrome: adding a sidebar, toolbar and status bar panels, at very least. This raises all kinds of security concerns, I’m sure, but at the end of the day if the app is written entirely in JavaScript with standard web privileges, it can’t do anything too heinous. Perhaps the biggest barrier is cracking the nut of dynamically loading and unloading overlays. This is tricky and it doesn’t look like anyone’s working on it right now. Hopefully someone will pick up the ball since this is, in my opinion, one of the biggest barriers to adoption of Firefox extensions in general. Perhaps the best approach would be to start a green field effort to enable web apps to modify the browser’s chrome in controlled ways, rather than trying to adapt the existing extension mechanism.
Back in June we announced that we would be making available a bundle of Firefox with AllPeers preinstalled, in partnership with Mozilla. The product has been a resounding success, and we just passed the 25,000 download mark last week.
This means that over the past four months, we’ve helped to bring over 25,000 new users into the Firefox fold. Another interesting tidbit: out of the 13 languages that have been downloaded, English is the most popular (nothing surprising there) followed by French and then by Chinese, which narrowly nips out German. If our statistics are any guide, the rise of Firefox in China is well underway.
The Mozilla folks have been absolutely fantastic in helping us to put this bundle together. We hope we can continue to return the favor by doing our part to bring new users to Firefox.
TorrentFreak is running an interview with me about our Social BitTorrent functionality, present and future.
I’ve become totally enamored with singular they, which provides a completely natural-feeling solution to the thorny problem of gender-neutral pronouns. As a consequence, I just found myself writing “themself” and doing a double take when my spell checker flagged it. A little research revealed that the Language Log has been there already. From my perspective, themself is a logical corollary of singular they, and I’ll be using it unashamedly in my writing. After all, 1.6 million Google hits can’t be wrong, can they?
Daniel Glazman has a followup post on the whole “Powered by Mozilla” thing (excellent initiative, did I mention?), which points to a droll and frustratingly anonymous rant on a new blog called “The Truth about Mozilla”.
I fell off my chair when I read that AllPeers is a “Mozpad front-company” and not just because of the incorrect hyphenation. (Save your cards, flowers and chocolates, I’m fine beyond a few psychological bumps and bruises.) That said, Mr. Anonymous does provide a reasonable if caustic counterpoint to Daniel’s and my contention that Mozilla platform developers would benefit if there were some way for them to leverage the better-known Firefox brand. (But what’s all this about Schrödinger’s cat? I’ve heard of mixing metaphors, but throwing in a physics thought experiment is a bold move. What good shit are you smoking, dude?)
Anyway, as my previous post on the topic implies, I disagree with the idea of trying to create a second trips-off-the-tongue brand out of Mozilla. Like I said, it’s hard enough to get traction with even one brand. As things stand, I must say “you know, the guys who make Firefox” about ten times a day.
And then there’s the general problem of what to call the platform. Mozilla, Gecko and XULRunner are often used interchangeably, and all of them have considerable drawbacks. Calling the platform “Firefox” is obviously problematic too, as Anonymous Mozilla Guy points out. But what about taking a feather out of BitTorrent’s cap? “Firefox DNA” is a bit me-too-ish. But something that uses the word “Firefox”, gets across the idea that “this is the stuff inside Firefox” while remaining clearly distinct from Firefox The Browser would be killer.
UPDATE: Before anyone else chastises me for “feeding the troll,” let me say in my defense that I didn’t read the earlier, more obnoxious posts on the “Truth about Mozilla” blog before linking to it. The post I link to seemed reasonable enough to me. I’d be on thin ice, after all, if I criticized his sarcastic tone and childish sense of humor (though I might plausibly demand royalties). Anyway, a lot of the posts do look like trolling, and the whole idea of a muck-raking Mozilla blog is silly, so please don’t patronize or link to his blog unless I explicitly say it’s okay.
UPDATE: Apparently it isn’t obvious that the bold portion of the previous update is tongue-in-cheek, at least if Cedric is any guide (a dubious premise, I admit). So lest it be too obtuse for some: I’m kidding!
I often talk to people who aren’t developers but still want to be able to contribute somehow to the open source world. If you have any kind of graphic design skills and want to support our effort to promote the Mozilla platform for developers, why not consider giving the Mozpad website a makeover? Let’s face it, considering the way it looks currently, it wouldn’t take much work to improve it.
Daniel Glazman comments on John Slater’s post about the excellent “Powered by Mozilla” initiative. I’ve seen this phenomenon directly or from a distance a number of times in my professional career. It’s hard to build a brand, and it’s doubly hard to build separate brands for a company and its flagship product.
In my experience, what inevitably happens is that the product garners much larger mind share, and the company eventually adopts its name in order to leverage its brand. Just thinking out loud, mind you…
When I got laminated for musing clumsily about the idea of Mozilla switching from Gecko to WebKit, I wish I had remembered that I blogged (way back in April 2005) that Apple should drop Safari in favor of Firefox.
To paraphrase the old saying, if you don’t like what I’m blogging about, wait ten minutes. (Well, two and a half years, but who’s counting?)
I’ve made the transition from Apple virgin to annoying fan boy in an amazingly short period of time (less than a year since I bought my first iPod shuffle and six months since I bought my first Mac). I am now the proud owner of a Mac Pro, Mac Book Pro, iPod Shuffle and iPhone. Like most Apple afficionados, I’m 90% blown away by the greatness of their products and 10% frustrated that they won’t do those few small things that would make them absolutely perfect. (I made this same remark a while back about the Shuffle specifically, but it applies equally to all Apple products I’m familiar with.)
Lately one of the biggest annoyances is the lack of support for gadget junkies like myself who own more than one device. It’s maddening, for example, that Apple portable music players can only be synced to one computer. In a more general sense, Apple devices don’t play together all that well if you break out of the “one computer, one portable device” mold.
Here’s what I want. First of all, it’s a no brainer that my iPhone should become an extension of not one, but both of my Macs. Whenever I’m within wifi or Bluetooth range of one of these machines, I want my iPhone to connect and sync automatically. In fact, I’d like to use my phone to sync the music libraries on my computers, since I often add new tracks to one or the other. So if I add new tracks to my laptop at work (like I did yesterday when I bought Radiohead’s new album), it should be copied to my phone and then to my Mac Pro at home without manual intervention on my part.
Moreover, there’s no reason for me to use the small iPhone screen when I’m sitting at my desk. So the entire UI and all features (including phoning) should be available to me from my computer as long as my phone is within range (as widgets, probably). When I’m listening to music on my computer and someone calls me, the music should fade out automatically just like it does so elegantly on the iPhone.
Finally, I’ve taken to using my phone instead of my Shuffle to listen to podcasts on the go. But there are times I’d rather use the latter, such as in the gym or when lounging around my apartment in sweatpants. But to do this I need to be able to dock the Shuffle to the iPhone, with an interface on the phone to copy over selected tracks. Tracks copied from the iPhone should remember their current position and, when I dock the devices together after finishing my workout, the position of the track on the phone should be updated. This may be the best argument yet, to my mind, for a native SDK so I can at least contemplate putting this together as a do-it-yourself hardware/software project. (Let’s face it, Apple’ll never do it.)
Paul Rouget and Mariano Cuenze have been pushing forward the Mozpad IDE project, and we’re all jazzed up by the potential of Open Komodo to serve as the basis for an IDE for Mozilla developers. Shane Caraveo of ActiveState (makers of Komodo) has kindly offered to provide some guidance as to how we can best extend their product. Paul has written up some preliminary requirements in PDF and ODT formats. (I promised I would edit the text for grammar, but it actually looks fine to me for our current purposes.)
We’ll be meeting tomorrow at 4pm UTC in #mozpad. If anyone else is interested in talking about a Mozpad IDE built on Open Komodo, please feel free to join in the discussion.
I’ve updated the Mozpad API analysis page with additional statistics I received for Mozilla projects. I am planning to massage the results in various ways to provide additional views (e.g. sorted by frequency rather than interface). but this should tide us over in the meantime.
Many thanks to Nick Nassar of Miro, Wladimir Palant of TomTom, Javier Pedemonte of the AJAX Toolkit Framework, Pete Wilson of Mozdev and Matt Crocker of Songbird for providing data for their projects. I ended up biting the bullet and compiling the figures from the various files I received using Python, which meant (wait for it) I had to learn Python on Friday. This went surprisingly well due to a very supportive group of folks on IRC, notably Jason Orendorff, who has made a Python convert out of me in less than an hour.
It goes without saying that we’d love to feed more data into the stats. Please take a few minutes to run the script on your project and send me the results.
I wrote a while back about our intern Luděk’s work on demonstrating how AllPeers can be extended by installing additional Firefox extensions that we call “extras”. The first extras added support for uploading images to Flickr and links to del.icio.us as part of the sharing process. They aren’t really ready for primetime, but they are good demonstrations of how one extension can extend another (in general) and how new features can be added to AllPeers (specifically).
Since then, Luděk has been hard at work writing additional AllPeers extras. It is certainly a goal for these to be useful to some AllPeers users. With a bit of luck they will also be useful for those thinking about the requirements for adding real support for extension dependencies to Firefox. And, ideally, we’ll eventually see third parties motivated to write extras for AllPeers. You can see all the extras currently available on our new extras page.
As far as the Flickr and del.icio.us extras are concerned, it occurred to me recently that a better approach would be for these (and potentially other services) to be available in a way analogous to normal contacts. So I can share an image with my friends Bob, Fred and “Flickr”. The latter would result in the image being uploaded to their website rather than being shared via the AllPeers network. Luděk seems to agree so expect to see this in a future version.
Another cool extra provides operating system shell integration. After installing it you get a new context menu option in your file manager to share files with AllPeers. This makes it quicker and easier to share files without having to go through a potentially cumbersome drag-and-drop process. It works both on Windows and on GNOME’s Nautilus, KDE’s Konqueror and Dolphin and XFCE’s Thunar (which I like to refer to collectively as “Linux stuff”).
The final extra lets you set up a special user who will automatically receive any files you share. So if you have one machine that’s always on, you can install the caching user there and be sure that your files will always be available even if the computer you shared from (e.g. your laptop) isn’t. This is an elegant solution to the “no sources” problem that plagues all peer-to-peer networks.
I hope that these will be of both educational and practical value to others. I’ll blog about other extras as they appear. If anyone has ideas, drop me a line.
Are you the lucky AllPeers user who will become the proud new owner of an iPod Nano? Sounds too good to be true? Just take a minute to let us know what you think by filling out our new survey about AllPeers. This will help us better understand how you use AllPeers so we can make it even better.
Note: In order to be eligible for the prize, contestants must complete the entire survey and provide their email address at the end of the survey. Only one entry per person. The winner will be hand picked on November 15th, 2007 and contacted directly.
I’ve had several people express strongly negative opinions to me about my Gecko vs. WebKit post. I would therefore like to clarify what I wrote and why I wrote it.
Three specific incidents spring to mind as motivations for the post. The first was at a conference last year, where a Mozilla core developer and I were admiring a portable electronic book that was amazingly easy on the eyes. The guy showing off the device told us that they had chosen some other rendering engine (I think it was Opera) because Mozilla was too heavy for their purposes. I ended up having a long discussion with the Mozilla guy about how to improve Gecko’s memory footprint, in particular by using a more efficient representation for the content tree based on a big hashtable, using tearoffs when access was needed to specific interfaces. And maybe switching from UTF-16 to UTF-8.
The second was an interview with Tristan Nitot on TechCrunch. Tristan expressed the view that allegations of Firefox’s bloat are unjustified, and many of the comments took him to task for this. A lot of TechCrunch commenters are idiots, of course, and the frustration I felt as a member of the Mozilla community on reading this was ironically similar, I’m sure, to that of a lot of people upon reading my post. Nonetheless, this really drove home to me the extent to which the perception that Firefox is a memory hog (justified or not) is widespread.
The third was last week, while on vacation with my new iPhone. Like everyone else who’s laid a hand on one, I’ve been totally seduced by the device. The web browser in particular is stunning. Well, actually it’s really slow, has no cache and lacks essential features like a clipboard and the ability to open a link in a new window or store files to disk. But it’s still the actual functioning web in your pocket. As a member of the Mozilla community, I was jealous.
From there it wasn’t much of a stretch to imagine a future Firefox based on WebKit. In retrospect, I regret two things about what I wrote. The first is that I left too much unsaid. I know that there are many difficult trade-offs in any large software development project, and Mozilla is about as big and complex as it gets. In many cases keeping memory usage to an absolute minimum was not the only goal. Much of the baggage that Gecko carries when compared to something like WebKit makes possible the extension mechanism that is Firefox’s biggest strength. You can’t have it both ways, and Mozilla is now implementing some of lessons learned (e.g. deCOMtamination) that will make Firefox leaner without sacrificing extensibility. Moreover, while I don’t think that running exhaustive benchmarks is a precondition for writing what I wrote, I should have made it clearer that I was basing my thesis on secondhand information and that it should therefore be taken with a grain of salt.
The second is the finality of my conclusion. I actually don’t believe that it’s a no brainer for Mozilla to drop Gecko; to believe so based on my limited knowledge (especially of WebKit) would be foolish. I got carried away by my own rhetoric and opted for a punchy ending. But it’s not a good idea to conclude controversial posts by voicing opinions that you don’t actually subscribe to. I should have said that it was an intriguing question worthy of investigation, not that Mozilla would be derelict if it didn’t jettison Gecko immediately. Sorry.
In part one of my apparently very occasional series on markup, we looked at the web’s equivalent of the Odd Couple: HTML and XHTML. Like Oscar Madison, HTML leaves its tags strewn all over the place, expecting the parser to clean up after it. (Hey, your mother doesn’t work here, HTML.) XHTML is a neat freak in the mold of Felix Unger, with its tags vetted against a document schema and nested just so. While the migration path to XML-based markup on the web might be fraught with difficulties, the motivation for taking it should be clear.
Nonetheless, some commenters questioned the value of an XML-based web. Even more controversial was the idea that browsers should reject pages containing ill-formed or invalid markup. Surely displaying something must be better than displaying nothing at all, right?
Actually the XML folks were adamant that XML should follow in SGML’s footsteps by rejecting bad markup. And in fact, the question of whether an XML web has value is the same as that of whether to try to milk something meaningful out of misbehaving pages. As soon as we accept markup that isn’t well-formed or valid, we can be sure that authors won’t bother to fix their mistakes. Don’t believe me? Surf to 99% of web pages and view source. The good news is that if major browser vendors enforced correct markup, authors would rapidly get a clue, just as they have been scrambling to fix pages that don’t play well in Firefox as the latter’s market share has grown.
The advantages of XML on the web are numerous. Simple text processing a la Perl can be used for more tasks. DOM processing is less confusing because strange invisible tags like tbody don’t get inserted by the parser. You can mix and match XHTML and other XML vocabularies like MathML and microformats.
By far the most significant argument for XML on the web, however, is the complexity of existing HTML processors, a direct result of the compatibility hacks required to deal with naughty content. One might argue that good, robust HTML processors like Gecko, WebKit and Presto make this issue moot. After all, if I can use a black box to pass me a nice clean DOM, why worry about what manner of malformed mutant markup it vacuumed up to do so?
The discussion around my previous post (along with a post by Robert O’Callahan with enough meat to keep a motivated student of browser technology busy for days) makes the answer abundantly clear: there’s plenty of scope for improving existing user agents, in terms of performance, security, hackability and footprint (static and dynamic). And the cruft that the current generation of HTML engines must accumulate to deal with real-world web markup is a huge barrier to progress.
The original XML working group aimed explicitly to keep the standard simple enough that the average CompSci grad student could write a complete parser in a weekend. Granted, they didn’t quite succeed in their goal, but an XML processor is still orders of magnitude less complex than its HTML equivalent, and that matters.
