Lightning can write, I promise

We’ve begun week two of the Summer of Code and the move to asynchronous storage based on promises continues. We are now at the point where events and tasks can be created using (I believe) code that is completely free of callbacks, with the exception of those that are need to serve the IDL interfaces. It’s been somewhat of a rough ride to get to this point, and I’ve learned a couple painful lessons about how asynchronous code works. From here the next step is to allow the rest of the calendar operations to be performed without using callbacks. Hopefully it will be a quicker process from here, as they share a large number of helper functions that have already been rewritten, and I’ve learned a thing or two along the way. Things are still being tracked in Bug 501689, for those who are interested.

First Patch of the Summer

Freedom at last! I took the final exam of the semester last Friday, and so summer break has officially begun. The coding period for Summer of Code began Monday, and the first patch to come out of it has been attached to Bug 501689. It’s still a work in progress, but several of the callback functions have been converted to the more modern promises. Like callback functions, promises help guarantee that a function has the data that it needs before it continues, but code written using promises instead is cleaner and much easier to follow. And, as I’ve discovered a couple times while working on this patch, promises have the additional benefit of pretty informative error messages when one fails.

The next step is to convert some of the helper functions to use Task.jsm, which returns a promise when completed, and makes the code a lot simpler and easier to read. One of the main difficulties in completely eliminating callbacks is that many of the IDL interfaces require several callbacks as arguments. There isn’t an easy way around this, and one of the goals is to limit the use of callbacks to that instance.

One of the things that has been made pretty clear to me already is just how large the Mozilla project is. It’s a pretty daunting mountain of code, but we’ve made some slow progress already. Hopefully as the summer goes on, I’ll continue to become more familiar and we can get things really moving.


Welcome to the summer! I’m a student at the University of Minnesota just finishing my sophomore year, planning to graduate with degrees in Chemistry and Computer Science. A couple days ago we finally got above 70° F (21°), and hopefully we won’t get a repeat of last year, with a foot of snow in May. I’m excited for the opportunity to work on the Lightning calendar project for the summer, and some of that work has already begun. To begin, I’ve checked out a patch written by one of the mentors, Philipp Kewisch (:Fallen), that makes Lightning’s storage system asynchronous. An asynchronous system allows the program to continue executing without waiting for a reply from the function that was called. This makes the program a lot more responsive, as hopefully you avoid the entire program hanging while waiting for information to return. Instead the work is just done in the background and the information is just returned before it’s needed. The current work is in Bug 501689, and it will hopefully bring about some significant performance improvements. I’ve finished fighting with Mercurial and have applied the older patch to the current code base, and begun converting the already written asynchronous code to use Promises, a newer way to ensure that the asynchronous call completes before the information returned by it is needed. There’s just a week left until the coding period really begins, and I’m excited to get started!