Last updated: 9/24/05
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:
TargetAlert will hit 0.9 when it has support for user-defined alerts.
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:
So why localstore.rdf instead of a separate targetalert.xml file under the profile directory?
- 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.
Unfortunately, there turned out to be some serious drawbacks to RDF that made localstore.rdf a poor choice:
- 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.
The new plan is to create a directory called targetalert under the profile directory in
the same way that ForecastFox
creates a forecastfox directory under the profile directory.
ForecastFox used to have some problems writing its profiles.xml file; sometimes the file
would get corrupted while being written and the user's preferences would be lost.
That problem has since been corrected by creating a backup file.
ForecastFox has also implemented a scheme that uses
XSLT to update profiles.xml between versions. Looking at the ForecastFox source code,
it is, in many ways, a model extension.
- 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:
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 :)