Google Summer of Code: Mozilla Projects

This article was originally published in LWN on 2007-08-20.

This is the fifth in LWN’s series of Google Summer of Code (GSoC) 2007 articles. The first four articles covered the program launch, Ubuntu’s projects, the OpenMRS organization, and one student who is tackling Direct3D 10 support for Wine.

After breaking into the Google Summer of Code last year, Mozilla is back again as a major mentoring organization. They were delegated nine projects last year and are hosting ten this year, the sixteenth most of the 137 participating organizations in the GSoC 2007. Moreover, due to the mainstream popularity of Firefox and Thunderbird, the code that Mozilla’s students are developing this summer will likely be among the most visible of any organization’s. This summer’s code is made all the more interesting by the concurrent ramp up in development prompted by the impending release of Firefox 3. Read on to learn about four of this prominent mentoring organization’s most interesting projects and hear from both the students and the mentors as they rush to complete their projects by Google’s final code deadline on August 20th.

Nick Kreeger’s “Enable Roaming Support in Thunderbird” (mentored by David Bienvenu)

Student Nick Kreeger has a great idea for anyone that reads their email with Thunderbird, Seamonkey, or his own Mac OSX mail client Correo from multiple computers at home, work, and anywhere else. Kreeger is integrating functionality into the Mail/News framework component that will allow all Mozilla-based email clients to synchronize preferences and address books through IMAP and POP accounts, though the feature must be integrated into the interface of each application. Kreeger has already coded the core roaming service for Mail/News with full support for IMAP (POP support is “coming along smoothly”). He will begin developing a Thunderbird interface to the service before the end of the GSoC, but he notes that it may wind up in an extension.

The synchronization is performed by passing email messages through the user’s mail account. The message will either contain a list of the changes a user has made to his preferences and address book or, after a set number of those “delta messages,” a full copy of the data for good measure. In an IMAP setup, these messages will be sequestered from users in hidden-unsubscribed folders, while for POP the mail client will simply hide the messages in the inbox. The core roaming service sends and retrieves these updates from the server and notifies the interface when new data is available. Kreeger notes, “We want to expand this synchronization to include saved searches, RSS feeds, mail filters, .newsrc files, tag definitions, views, and more.” He also intends to deliver full documentation on his code, but perhaps not until after the GSoC deadline.

A simple security precaution should keep at bay the potential security risk presented by accepting emails as application configurations. He explains, “We are planning to implement a PIN system for signing update messages in a similar fashion to how you can sign a messages with a certificate in Thunderbird.” Project updates can be found on Kreeger’s blog. The student recently graduated with a a Bachelors Degree in Information and Computer Science (Software Engineering Emphasis) from Park University near Kansas City, MO. Mentor David Bienvenu, who Kreeger credits with developing the concept behind the project, is a Mozilla module owner for the Thunderbird project and the Mail/News component.

Kunal Jain’s “Places: Indexing Visited Pages” (mentored by Dietrich Ayala)

Student Kunal Jain is vying to resolve one of Firefox’s longstanding feature requests, full-text search for visited pages. While Firefox derivative Flock has beat him to the punch by using CLucene for full text search, Jain is seeking a lighter-weight solution that will integrate seamlessly with the SQLite database which is already being used in Firefox 3’s Places bookmarking and history system. He settled on the FTS2 SQLite module and has developed a detailed strategy for its implementation.

The full text search feature will hook into the Places query system via the existing nsNavHistoryQuery class, which allows for searches constrained by date and time. The nsNavFullTextIndex class will be responsible for calling FTS2 to rifle through visited pages for search terms, and will index them when called by nsNavFullTextIndexHelper upon page request events. One last class, nsNavFullTextTokenizer, is a wrapper for FTS 2’s tokenizer that will prepare web pages for indexing by recognizing important terms and stripping HTML tags. Jain’s design underwent substantial renovation during the GSoC before reaching its final form. Mentor Dietrich Ayala writes, “We had to re-orient the design as the understanding of SQLite’s internals increased. We had terrific input from a hacker on SQLite’s full-text-indexing module, which was quite helpful.”

Unfortunately, not everything has gone as hoped for the project. As of August 8th, the design had been reworked and finalized, but no code had been written due to time-restricting duties at the student’s job. Jain insists that he would like to have a prototype ready by the end of the GSoC, but Ayala is not confident that it will be ready for inclusion in Firefox 3 when the code freeze begins on September fifth. Nonetheless, both mentor and student are pleased to present to the community with a strong foundation from which this valuable and widely-requested feature can be implemented correctly, perhaps for Firefox 4. Ayala explains, “This has been on Mozilla’s radar for a long time, and it’s great that Kunal has been able to lay the foundation for making this happen.”

Jain stresses that he will continue contributing to Mozilla past the impending GSoC deadline. Project updates may be found at his project’s page on the Mozilla wiki. Kunal Jain recently graduated with a Bachelor of Technology, Information Technology degree from Sri Venkateswara College of Engineering in Chennai, India. Dietrich Ayala has been a developer with Firefox since February of 2006 and has been involved with the session restore feature and, pertinently, Places.

Benjamin Karel “JPEG2000 Support for Firefox” (mentored by Stuart Parmenter)

JPEG2000, the revamped JPEG format with “state-of-the-art compression techniques based on wavelet technology,” was introduced about seven years ago. While the merits of JPEG2000 for various applications are debatable, its arguably higher image quality at high compression rates would seem to make it a good fit for the web. While compression and decompression are costlier with JPEG2000, the price of bandwidth versus processor time may justify the newer format for everyday web applications. Unfortunately, JPEG2000 support among browsers remains a rarity. Computer Imaging developer Mike Chaney argued two years ago on the reputable Steve’s Digicams that “software manufacturers… are waiting for camera manufacturers to start supporting JPEG2000 as a native format in cameras and other devices. In turn, the camera manufacturers are waiting for global acceptance of the format in tools like web browsers, image management tools, photo editors, and other software.” The situation today seems identical to that at the time of his writing and, indeed, to the climate surrounding the release of JPEG2000 seven years ago - just look at the Mozilla bug report (assigned to mentor Stuart Parmenter) where, year after year, users encourage Firefox to “stand out from the crowd” with JPEG2000 support.

This summer, student Benjamin Karel has done his part to spur mainstream JPEG2000 support. He has developed an extension for rendering JPEG 2000 which is compatible with both Firefox 2 and 3 (the codebase for them is the same, though he notes that each version requires a separate extension). His extension implements the free software JasPer decoder and can correctly render all nine JPEG2000 conformance test files, though Karel raises issue with JasPer’s documentation and some aspects of its compatibility with particular caveats of the JPEG2000 specification. Despite various time-consuming personal obligations and wisdom tooth surgery, his project has been a success.

Nonetheless, roadblocks remain to the mainstream adoption of JPEG2000, even among the distinct subset of web users which Firefox represents. Both Karel and Parmenter agree that it would be inappropriate to integrate the feature with the Firefox trunk where it would see more widespread use than as an extension. Karel’s code would add about 150KB to the browser’s famously stingy download size and contribute that much more to Mozilla’s support obligations. Karel notes that his code would be more likely to be accepted if the state of JPEG2000 support was better in graphics editing tools, but he admits, “It’s a chicken-and-egg problem, yes, but it’s not Mozilla’s problem. Their job is to spend their limited resources as efficiently as possible.” Parmenter says, “Once the extension gets published we can get a lot more eyes on it and get some of that additional testing we would want before shipping it with our main product.”

Karel would like to develop an image-decoder finding service for Firefox that would recommend extensions like his own when users come up against an unsupported image format. Parmenter adds, “I would love to see an extension for things such as HD Photo and TIFF.” It seems likely that Mozilla will elect to use a model like this for supporting burgeoning image formats in their sheltered flagship product. Karel’s blog carries updates on his project. Karel is an undergraduate Computer Science student at the University of Delaware, while Parmenter is a Mozilla veteran since 1998, heavily involved in nearly every aspect of their products’ graphics technology.

Over two years ago, now, mentor Gervase Markham posted an ingenious idea to his blog. Even the best of us, he realized, are often too lazy to compare the checksums that are posted alongside Linux ISOs and other content online. Others may not even be aware of the process. The consequence is corrupted downloads and an increased risk for trojaned files being exchanged over the Internet. His solution was to include the checksum as metadata in the URL of the file itself so that browser download managers could automatically verify files. The implementation would not affect older browsers and those which choose not to support it and would appear transparent to users. Having been involved with the Firefox community for a few years as a bug sweeper, student Edward Lee jumped on the old idea this summer in order to give himself a crash course on the browser’s codebase.

Lee developed the idea into a draft specification for the Internet Engineering Task Force. His submitted design states that the checksum would be included as a fragment identifier, meaning that it would be information appended to a URL specifically for the user agent (web browser or download manager). URLs with link fingerprints would look like this: https://mirror.com/file#hash(sha256:abc123). While any hashing algorithm could be supported in this fashion, Lee chose to encourage initial standardization around sha256. A file’s hash would be calculated incrementally while downloading so that it could be compared immediately once transferred. In the uncommon event that the file fails to verify with the checksum, the user would be notified and advised to alert the content provider.

By the mid-term evaluation deadline on July 9th, Lee had an implementation of the system working and tested. He had integrated his code with Necko, Mozilla’s low-lying networking library whose features automatically filter up to Firefox, Thunderbird, and other products built on the Mozilla Platform. Soon afterward, Lee writes, things came to a halt: “The decision to not implement Link Fingerprints in Necko came from Brendan Eich (Mozilla CTO) and Christian Biesinger (Necko module owner) who felt that implementing this non-standardized feature in a way that coupled itself closely to the networking code would potentially hurt everything else built on top of Necko in the long run.” After some fidgeting with different implementations, the project was more or less abandoned. Meanwhile, Lee notes critical reception from the IETF community: “Major complaints include unnecessarily overloading the URI with additional metadata in a way that would make it difficult for new uses of the fragment identifier for other MIME types, as well as using the fragment identifier for a purpose that it wasn’t intended for.” While things seem bleak for link fingerprinting, Markham does indicate that there is some interest among download manager developers and there remains a slight possibility that the feature will eventually appear in the Firefox 3 download manager. Updates may be found on Mozilla’s Bugzilla entry for Link Fingerprints.

Lee has been able to expend his newfound familiarity with the Firefox codebase into other development areas. He has begun working on features for the Firefox 3 download manager and the new JavaScript engine ActionMonkey. He reports favorably of his experience with the project: “For those interested in hacking on Firefox, it turns out it’s not too difficult to do so; just hop on IRC and ask around and people are bound to help if one asks nicely and remains patient.” Lee will begin pursuing a Ph.D. in Computer Architecture/Compilers this Fall at the University of Illinois at Urbana Champaign. Markham has been, in his own words, a “Loose Cannon” at Mozilla since January 2000, principally involved with project governance.