Last week marked midterms for the Summer of Code. I’m happy to say we’ve moved past the midterms and that a patch has been submitted for review on the asynchronous storage system. There’s a fair amount of testing that will need to be done to ensure its correctness but from a code standpoint it is (hopefully) finished. From here there’s work to be done on moving where calendar metadata is stored, and then the work on moving to a cache only backend for CalDAV and ICS can begin. To begin, this will mean cleaning up several bugs that have been reported in the cache system. Following that, the major work on conversion to a cache only system can begin. I’m looking forward to a productive second half of the summer of code!
One of the primary issues with the current patch to update Lightning to use asynchronous storage is that when a timezone upgrade has to be performed, a database operation has to be performed on each item. This can make for a (likely) extensive process, and could potentially hang the program while the update is being performed. The obvious solution is to convert the upgrade to be asynchronous as well, but that comes with a lot of undesirable side effects. If a user changes the time an event starts before the upgrade finishes in the background, confusion over the correct start time would occur. As a result, currently I’m working on a progress dialog so that the user knows what’s happening, instead of the program silently hanging. This may not be the best solution, but timezone upgrades generally do not have to be performed that often. We are getting closer to putting the finishing touches on the patch, and on a Summer of Code related note, midterms are next week. The hope is to have the asynchronous storage patch reviewed and commited by the end of next week, as well as some more work done on the movement of metadata.
The work continues. It’s not quite finished, but a patch that’s getting close has been attached to Bug 501689 for feedback. In the mean time, we’ve begun looking at moving item metadata from the provider interface to the item interface. While not a necessity for either async storage or a cache-only system, it comes with some benefits. As it currently is, each provider would have to duplicate code to retrieve the item specific metadata that we want. If we save this with the item, the code can be kept a lot cleaner. It’s the next step, and once completed we can begin looking forward to doing the real work on implementing a cache-only system.
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.
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!