Roadmap

If you have followed the history of TargetAlert, then you have probably noticed that the 0.8.x series has been going on for awhile and what to know when it's going turn over to 0.9, so here's the deal:

This has been a feature request since day 0, so some of you may be wondering what has been taking so long. The tricky thing has been deciding how and where to store the user's data. A bad design decision here makes it very difficult to transfer a user's preferences when a new version of TargetAlert is released, assuming the new version requires preferences to be stored in a different format.

Prior to version 0.8, TargetAlert preferences were stored in the general preference store which you can view in about:config in your browser. From what I've read, about:config is not a source of pride for Mozilla, in that it's an unsightly dogpile of information. True, a number of extensions store their preferences here, and this is acceptable when an extension only stores a small, finite amount of data. (TargetAlert has to be able to store an infinite amount of data once it lets users define their own alerts.) Though the number of entries that an extension can add to this store is unbounded, it seems sloppy to clog up this file. True, an extension could store all of its data in one long string preference that could be serialized and deserialized, but that would make it very difficult for users to edit the data in about:config, which is the main benefit of having about:config in the first place.

In 0.8, TargetAlert preferences moved from the general preference store into localstore.rdf. In general, I knew that I wanted to use some sort of XML file to store preferences because:

• Future versions of TargetAlert could use an XSLT to change the format of the data, if necessary.
• The data would be stored in a human-readable/human-editable format, which is helpful for debugging and also a convenience for users who are curious to see what information the extension records.
• Mozilla/Firefox has good tools for reading and writing XML data.

• I have seen many web sites complaining about what a pain it is to locate a user's profile in a way that works on all platforms, so I thought that using an existing XML file for which Firefox already provided an API would be easier.
• XUL trees have support for reading directly from an RDF file, so this would simplify my options dialog.

• I found the API for RDF very tedious; it required too much code to do simple things.
• The order that items are listed within the file itself is unspecified, so it is not easily human-readable.

There are a few other improvements that storing TargetAlert preferences in XML will bring:

• TargetAlert will no longer use the feature that reads directly from RDF into a XUL tree. Using this feature is currently responsible for the problem in the options dialog that causes the table of alerts to "jump" when the user toggles the Enabled? field. It will be nice to eliminate this bug.
• A proper Apply button in the options dialog should only be enabled when the user has changed something that will actually alter the options. Implementing such a button will be relatively straightforward because the state of the options dialog can be stored in an XML tree which can be compared with the XML tree of the user's options currently in memory. This test would be done every time a user types in a form field or clicks a button. The Apply button would be enabled appropriately as a result of this test.
• This will eliminate all the junk that TargetAlert adds to localstore.rdf. The "junk" isn't harmful in any way, since no one should ever have to look at localstore.rdf anyway, but it did elicit this [2-star] comment on the Mozilla Update site:

  Messy
  by don, Saturday, July 16 2005
  
  Uninstall TargetAlert. Now, open localstore.rdf in Notepad,
  and look at how many references to TargetAlert remain.
  Now, open chrome.rdf and do the same. Nonsense.
  

  I thought this was a pretty thoughtless comment since the tidiness of localstore.rdf is not an issue for many users. The complaints I get about TargetAlert are pretty creative sometimes.
• TargetAlert could support an import/export feature that would basically read in another friend's targetalert.xml file and present the user with a dialog asking which alerts the user would like to import.

So that's the plan. The remaining issue that I have not fully thought through is what the format of targetalert.xml should be. Obviously, I could do something analogous to what I currently do in localstore.rdf, but I need to make sure that it is flexible enough to support everything on the Future Goals list, even if some of those items will not be implemented for some time.

The one other issue is finding the time to write all that code :)