Dmitry Jemerov's Weblog

Mozilla bookmarks synchronization

As I've started to write fairly regularly about technical topics to my LiveJournal, I thought I might as well cover these topics here... it's better than no blogging, in any case.

One of the few remaining features that we had planned for OmniaMea 1.0 is bookmark synchronization with Mozilla/Firefox. Today we have finally investigated what this feature really costs, and the results were not too pleasant.

First of all, in order to correctly locate all Mozilla profiles, we would need to create a parser for the profile registry, which is stored in a custom binary format. It looks as if Netscape developers created a new universal, powerful and extensible data format for every single data storage task that they encountered during development. While the format of the profile registry is much simpler and more reasonable than the history.dat format, a simpler general-purpose format (like XML or even RFC-822) would have suited the task just as well, and would be much easier to use for external developers.

Given the time constraints, we decided that we won't currently develop the profile registry parser, and will simply scan the two profile roots (Mozilla and Phoenix) and offer the user to choose one of all the profiles we will find.

A much more significant problem is that export of bookmarks to Mozilla seems totally impossible. The reason is that Mozilla always saves its bookmarks.html file when exiting, and that would overwrite any changes that we could make in that file when bookmarks are added or changed in OmniaMea. Synchronizing the bookmarks when Mozilla is not running is pretty much useless, because in general there is no reason to ever close the browser. (Myself, usually I start the browser as soon as I power on the PC and keep it running until the next reboot.) And I don't know of any way to update the list of bookmarks in a running instance of Mozilla.

On the other hand, while the structure of the Internet Explorer favorites folder is considerably more complex than a plain-text file, we can parse it entirely using the operating system API, and we can create or change favorites at any time with no problems.

And even though the open-source nature of Mozilla allows us to solve these problems ourselves, and we probably could spend a man-week or two to develop the patches and push them into Mozilla 1.8, this makes no real sense to us. First, a majority of users would still use earlier Mozilla versions, and wouldn't be able to benefit from our work. And second, with our small team, we'd very much rather spend our time improving our product, not some other loosely related ones.