Archive for the 'Programming' Category

Firefox 3 will include several heavy-hitting changes to extension development, some of which will cause existing extensions to break. Let’s take a look at what’s changing, to get an idea of what to expect from a development point of view:

New APIs
One big change that will likely break some existing extensions are the new Firefox APIs being introduced in 3.0. All of the bookmark and history APIs are changing radically, with the introduction of the new Places architecture. As such, any extensions that make use of these will need substantial work to run properly in Firefox 3. Similarly, any extensions that use the Password storage functionality in Firefox will need changes (a new login manager will be used to handle stored passwords). It remains to be seen how one will develop an extension that will be compatible across all versions of Firefox. I haven’t seen any mention of simply deprecating the existing API calls, though I would hope that’s what the developers would do.

Secure Updates
Firefox 3 will require that all extension updates be provided over a secure channel, to avoid man-in-the-middle attacks. This means that if you are not using the official addons.mozilla.org website to host your extensions, you must provide your own secure method of distributing updates. One has several options for doing this:

1. The updateURL must either use https or not be provided at all.

This method assumes that you either host with the official site (thereby not using an updateURL value at all), or you are willing to host your extensions from a secure location using https. The latter option will likely cost you money, while the former forces you to use a website beyond your personal control.

2. The updateURL uses http and the updateKey entry is specified.

This second option seems a little easier to swallow, though it will involve a little extra effort on the behalf of extension developers. First, an updateKey value must be provided in your extension’s install.rdf file. Second, a digital signature must also be included in the update manifest; otherwise, the update will be rejected. Your updateLink value can either use https, or it can use http while providing an updateHash value. The updateHash value can be generated using either a sha1, sha256, sha384, or sha512 hash algorithm. But take note: you should not use sha384 or sha512 as of this writing. This forum thread mentions bug 383390, in which both sha384 and sha512 values are incorrectly truncated by Firefox 2.x (making backwards compatibility a problem).

Some further information about this new signing process can be found here.

Other Changes
The two items above aren’t the only changes coming down the pipeline for extension development, but they are the largest changes that I can see. A document detailing the new items is available, and should (hopefully) be updated as 3.0 nears an actual release date. It looks like extension developers will have a fair amount of work coming up, but I think these changes will be beneficial in the long run. How well the community accepts these changes remains to be seen.

Another new recurring feature I’m going to try out here at the site are programming tip ‘grab bags.’ These will often feature a few tips I’ve picked up over the years, which I find highly useful. We’ll start out this inaugural article with a few Perl tips:

Read the rest of this entry »

I’ve recently been wrangling with some Perl code for a project at work, and have been putting together a Perl module that includes a number of common functions that I need. As such, I had to remind myself how to create a Perl module. During my initial development, I ran into a number of problems, but I eventually worked through all of them. In the hopes of helping myself remember how to do this, and to help any other burgeoning Perl developers, I’ve written the following little guide. Hopefully it will help shed some light on this subject.

Read the rest of this entry »

I’ve rolled out some upgrades to the software I use here at the site for my photo albums. Here’s the list of improvements:

• Clean URLs are now used through the magic of URL rewriting. I think I’ve gotten most of the kinks worked out with this, but WordPress feels like it should control everything on the site. I’ll be making a post later this week on what I had to do to get things to work.
• HTML is now supported in all my photo captions. I’ve added a few links to a few of the photos, and I’m looking forward to using this feature on future albums. I hope to add this functionality to album descriptions eventually.
• The header image is no longer shown on photo album pages. This reduces the height of the page, reducing the need to scroll down.
• Extended photo information is now shown in a table using four columns instead of two, again reducing the height of the page.
• A new database backend is being used (the MySQLi extension instead of the raw MySQL PHP calls).
• A photo gallery title is no longer shown on each album page.

I want to add comments eventually, but there’s more effort involved in doing that than I want to spend right now. If you notice any problems, please let me know about them. I’m aware of a minor bug in my rewriting code (no regular users should encounter it), but I hope to fix it in the coming days.

While working on my rewrite of MonkeyAlbum, I ran into an interesting programming dilemma. In the past week or so, I’ve been introduced to the MySQLi extension in PHP. The current MonkeyAlbum implementation makes use of the PHP 4 mysql_*() calls, so I thought I’d try out the MySQLi interface to see how it works.

MySQLi includes support for what are known as “prepared statements” (only available in MySQL 4.1 and later). A prepared statement basically gives you three advantages: (1) SQL logic is separated from the data being supplied, (2) incoming data is sanitized for you which increases security, and (3) performance is increased, since a given statement only needs to be parsed a single time.

It seems to me that the performance benefit can only be seen in situations where the query is executed multiple times (in a loop, for example). In fact, an article on prepared statements confirms this suspicion; the author in fact mentions that prepared statements can be slower for queries executed only once.

So here’s the problem I face: the queries that get executed in MonkeyAlbum are, for the most part, only ever executed once. So, do I make use of prepared statements just to get the security benefit? It doesn’t seem worth it to me, since I can get the same security by escaping all user input (something I already do today). Does someone with more knowledge of this stuff have an opinion? If so, please share it.

In his seminal book The Mythical Man-Month, Fred Brooks devotes an entire chapter to one particular idea in software development: plan to throw one away. Though I failed to complete the planning part of his recommendation, I do intend to throw away the current version of my photo album package, MonkeyAlbum, which I employ here at this website. There are a number of improvements I wish to make to the package:

• Allow user comments for each photograph.
• Use cruft-free URLs instead of the ugly query strings currently in use.
• Improve captioning capability, allowing URLs and HTML formatting.
• Other, behind the scenes improvements.

All of this is in the concept stage at the moment, so what suggestions might you have for improvements? Are there things you dislike about the way I present my photos here at this site? Feel free to comment.

I am in the process of improving the accessibility of my photo album here at the site. My primary goal is to make the alternate text representations of each image something worthwhile, instead of the filename cop-out that I chose a while back. Each image now has an associated alt-text data record, and entering these by hand one at a time (there is no mass-update capability at the moment) is taking quite a while. As of this writing, I have provided alt-text values for six of the ten albums that I have posted. I hope to have them all completed by tomorrow.

You will find that the alternate text for the album thumbnail is rather weak at the moment (’Thumbnail for album XYZ’). This is due to the unfortunate way I constructed the various database tables. I essentially cannot obtain the alternate text record for the album’s thumbnail image, since I store the filename for the thumbnail, not the corresponding image ID. Later on I may improve this text, but I’m going to leave it as is for the moment. The alternate text for each full size image, along with each image’s thumbnail, has been greatly improved, and that was what I set out to do.