Shawn Wilsher

I’m in Whistler, BC right now for a Firefox/Mozilla summit. If you need to get in touch with me, your best bet is e-mail.

If you want to see what’s going on, check out this site!

This is the second time I’ve left a note on a car for parking in my parking spot. I’m more angry because I’m going out of town for the next five days and really want to park my new car in a covered parking spot! Rawr!

/rant

I meant to get to this yesterday, but yesterday turned out to be a busy day. I meant to get to this earlier today, but today turned out to be a busy day too…

As I previously announced, I’m going to try an experiment with sheriffing the tree. While I’m the acting sheriff tomorrow (that will be from 9am - 6pm EDT), you’ll have to run checkins through me. To make this easy as possible, there are going to be a number of ways in which you can get a patch to me (in the preferred order):

• Send me an e-mail with your hg bundle that includes the correct commit message.
• Attach your hg bundle to the bug you want pushed, and add that bug to the wiki page.
• Just post a bug number on the wiki page with the appropriate checkin comment.

I’ll also be going through checkin-needed bugs when things are slow. The general rule here though is that it’s a first-come, first-serve push ordering. I might take things out of order if the queue is big and I see bugs/patches that won’t interfere with each other.

Hopefully that clears up any confusion about tomorrow. I apologize for not getting this out sooner, but today was crazy. :)

I’m up for sheriff duty this Thursday, and I thought I might try something that people have discussed many times. It’s a bit radical, and I’m not sure if people will like it though. The idea is to only have the sheriff push changesets. This way, the sheriff can push things at a rate he/she is comfortable with, and stay on top of all the performance charts and random oranges. If it happens to be a slow day, I’ll be going through the checkin-needed bugs and pushing those as well.

It makes sheriffing a full time job, but I think it’s worth a try to see how it works out. I also think it will be a valuable data point to determine if we want to do it like this all the time.

Feedback wanted (posting to dev.planning as well)!

That asynchronous storage API I’ve been working on for a while has finally been pushed to mozilla-central. That means you can now run database queries off the main thread without blocking the UI. This includes both read and write statements.

This may not seem like a big deal, but there is a big benefit to using this API over the existing synchronous API. SQLite performs a file system operation called fsync which pushes the data in the file system’s cache to the disk. This operation is inherently synchronous, and on some file systems (like ext3), can take substantial amount of time given the right circumstances. If this is ran on the main thread, the UI is locked up the whole time. By using this new asynchronous API, you won’t have to worry about that fsync holding up the main thread at all!

Perhaps the best part about this new API is that it doesn’t require many code changes. You still create SQL statements the same way, but instead of calling execute or executeStep on the prepared statement, you just have to call executeAsync. The method takes one parameter - a callback that notifies on completion, error, and results. The callback is optional on the off chance that consumers don’t care if something finishes successfully or not.

Iterating through results is not much different from before either. The only difference is that results may be chunked, so the callback may get notified about results several times (with only the new data). Some good example code can be found in the tests that landed with this new API.

I’d really like people to try it out and see if they have any issues with the API. There are already a few refinements with bugs filed, and a few more up in my head that we might want if the need arises.