theme selector

light blue screenshot grey screenshot navy screenshot dark green screenshot red and black screenshot
 

by Tony Chang
tony@ponderer.org

All opinions on this site are my own and do not represent those of my employer.

Creative Commons Attribution License

website javascript to extension javascript

Oct 01, 2006, 06:37pm EDT

 

 

Steve has a great post about javascript and browsers. It includes a good example of some of the complexities of some of the Mozilla interfaces. [1] It’s a bit surprising if you come from the land of site javascript development and web apps in php/python/perl/ruby. My journey into extension development went something like this:

Start learning javascript by viewing the source on lots of web pages. Play around a lot by copying and pasting bits of code for other sites. Come to the realization that Firefox extensions are mostly just javascript code and find some tutorials online. Learn that XUL is easy because it’s just like HTML and JS in an extension is the same as JS on a web page. Make some basic “hello world” style extensions that do simple stuff like put an icon in the browser status bar.

A few days later, realize that if there are multiple browser windows, my new icon in the status bar doesn’t stay synchronized with the other windows. Oh, each browser window creates a copy of my JS code. Hmm, now I need to find a way to keep everything synchronized. Well, I guess I can use the observer service to send messages between windows.

So that works, but now I want to keep state persistent between browser sessions. So I’ll store some data in the prefs system. Hey, I can even use pref observers to keep data in sync. But wait, my data’s a bit more complicated than strings, numbers and booleans. So I need to serialize it somehow into a pref. Well, maybe I can use XML for that. Yeah, I’ll just make my own XML format and just store data that way.

And that brings us (kind of) back to data stored in XML formats. The weird thing is that XML isn’t really something that web developers store data in (it’s more of a transfer mechanism), so jumping from web sites to extensions tastes funny. It would feel more natural if I could just use a MySQL database to store my data.

Fortunately, extension developers do get a database in Firefox 2.0. Sqlite is now embedded and comes with a scriptable interface for using it. This makes data much easier to manipulate for web hackers. Furthermore, some of the internal data stores have already moved to using the mozStorage interface, making them easier to work with and easier to understand. [2] It also makes it easier to get data out of your Firefox profile to use in other apps when it’s in a sqlite db.

I’m hoping that all this means that there will be more extension developers and better extensions coming for Firefox 2 users. [3]

[1] I don’t know enough about the history of why bookmarks are in an rdf datastore, but I’m sure there were good reasons at the time.

[2] We’re not quite there for bookmarks and browsing history, but it’s on the horizon.

[3] I’m sure there will be plenty of crappy extensions too. The double edge sword of sqlite is that look ups can be more expensive (disk hit if not in the cache).

DC at Oct 02, 2006, 12:57am EDT

I find myself going back and forth on this kind of issue. Usually, I’m all about code simplicity, readability, etc., but the browser is like the thing that is used 90% of the time on the computer (slight exaggeration). This would be the one place I would think might require more focus on performance.