Mork: Half-life of a Bad Data Format
I’ve recently been working on a small project that needs to access the history data of the Firefox browser. Unfortunately for me (and many others who have run across the same problem), Firefox uses a file format called Mork.
Bad Format
Mork is just an appalling data format. Needlessly complicated, poorly documented and defying any rational reason for its existence. I’ll leave it to others to give it the critique it richly deserves:
- Jamie Zawinski: ‘This is just about the stupidest file format I’ve ever seen.’
- Defect entry in Bugzilla for Mork
- Blake Ross (Firefox co-founder) on the ‘Mork disease’
- Mork: A case study in ‘clever’ programming
Fortunately, Jamie Zawinski already wrote a Mork parser (in Perl), so my project can proceed with minimal pain. But if a parser hadn’t existed, the project would have been toast - I simply would not be prepared to spend time trying to write a parser for Mork.
Half-life
Mork was introduced in Mozilla (released in June, 2002), whereas previous versions of Netscape Navigator used a Berkeley DBM file. Firefox 3.0 will finally drop Mork (it was meant to have been dropped in 2.0, but the feature got delayed). So it will have taken about 5 years to remove the format from the code base. I’d expect Mork to live on for at least another 5 years, as users and organisations will not immediately upgrade their versions of Firefox.
Life in a goldfish bowl…
The author of Mork has taken a lot of very public criticism for the format, by pretty much anyone who has had to deal with it. A lot of the criticisms of the format are laced with insults aimed at the author of Mork, which I think are unnecessary.
But that’s the thing with an Open Source project, especially a high profile Open Source project. There really is no place to hide - people will look at your code and the design decisions you have made, and call you on them. And this is a good thing - unless you have an agenda you want to pursue (eg. implementing a database subsystem, because that is what you really want to be working on).
With propreitary systems and especially in the context of enterprise development, the scope for criticism is a lot more limited. Bad design decisions have a long, expensive half-life in software. Design and code reviews can go a long way to ensure that your project wont suffer something like the ‘Mork disease’.