Wandering Thoughts archives

The irritation of single-context applications

One of the extra irritations of many single instance applications is that they also are what I will call 'single context applications', applications where you can only be doing one thing at a time. I want applications like my feed reader or my mail reader to behave more like a browser, letting me rip off windows so that I can skip around without having to lose the old context.

For example, consider a mail reader. If I'm working my way through sorting and cross-checking older mail and new mail comes in, I don't want to abandon my place in the old mail to go read the new message. I want to just rip off a new mail reading window and use that to jump to the new messages. And if the new messages need me to look something up in my archives, I don't want to abandon the new message; I want to open another new window.

(If you prefer, substitute tabs for windows in this.)

Of course the irony of praising the browser's approach to this is that modern AJAX-based browser applications can easily throw this away, creating single context applications inside of the very thing that has done the most to show us a multi-context way of operating. (But they don't have to. I'm pleased to see that Google Reader is multi-context, for example.)

This problem isn't unique to single instance applications, but they do mean that you can't get around it, no matter how big a machine or how much memory you're willing to let multiple copies of the program use up. (And single instance applications don't necessarily have this problem, as Firefox demonstrates.)

The appeal of XML

For a long time, I was not at all fond of XML. The grandiose claims of universal document exchanges, universal editors, and so on were clearly bogus; as lots of people said, understanding the syntax gives you no clue about the semantics. It all smelled of hype and overselling, with XML the latest in a long line of next big things for the enterprisey market.

Then it struck me one day:

XML is a great way to not write a parser.

If you need to write and then read back some data, you need to parse your file format (and to generate it). But parsers are a solved problem; unless you have unusual needs, writing a parser (and its inverse, a generator) is tedious and boring, a necessary expense that you slog through in order to get your program to save and load data.

XML handles the low level parsing and generating for you. You still have to serialize and deserialize your data, but you'd have to do that anyways (even if the deserialization was hidden in parser actions and so on).

(XML also gets you out of having to design an actual file format, although you still have to come up with the serialization and so on.)

This has made XML a lot more attractive to me, to the point where I can imagine using it in my own programs if I need a save format for something.

(Of course, you get the same benefits from any widely supported and reasonably flexible format. These days JSON probably qualifies, and it's a good match for the native data structures in things like Python and Ruby.)