One Who Rides a Tiger Will Find It Hard To Dismount

Or, how Apple will revolutionize blogging (maybe).

Warning: Heavier doses than normal of geekery ahead.

When Safari was first introduced waaaaaaaaaaaay back in January of 2003, one of the biggest questions that was asked (other than “why do we need another browser?”) was “Why is Safari built on top of KHTML and why isn’t it based on Mozilla?”

The answer given at the time was that the KHTML engine, while perhaps somewhat immature compared to the Mozilla engine, was just as fast, but more importantly, much smaller and easier to work with.

This was true as far as it went, but it left out why being smaller and relatively cruft-free was really important: Safari’s rendering engine, called WebCore, was eventually going to be rolled into Mac OS X itself. In fact, you can actually consider Safari, the application, to simply be a wrapper around WebCore, an OS-level HTML rendering engine (this is oversimplification, but it works for our purposes).

Obviously, if you’re going to be rolling code into the OS proper, it helps if the code is as small and as cruft-free as possible. But why does Mac OS X really need an OS-level HTML renderer (other than the fact that Windows has one)? I mean, it makes some things, like improving the HTML rendering in HelpViewer and Mail.app, much simpler.

But that’s fairly trivial.

What if HTML was used in a really out-of-the-box way? Say, what if HTML (with a few minor extensions) was used as a lightweight way to build front ends for programs? That’s definitely an application that would require an OS-level HTML rendering engine.

Smells like Dashboard, doesn’t it?

Since Dashboard’s HTML extensions are part of WebCore, incorporating them (and thus virtually all of Dashboard’s functionality) into Safari (or any other application that uses WebCore) is already a fait accompli; all you have to do is make the specs for the Dashboard extensions public and all of a sudden, you’ve got Browser Wars II: Electric Boogaloo!

And who woulda thunk that all this would have happened all the way back in January of 2003, when all anyone wanted to know was “Why didn’t they use Mozilla?”

Now the past is prologue.

To anyone paying attention, it’s no secret that Apple is (perhaps belatedly) embracing blogging in a big way in OS X 10.4, aka Tiger. RSS support is being built into the next version of Safari and Tiger Server featuring a turnkey blogging server. The blogging server is built around blojsam, a blogging system that was inspired by blosxom.

Blosxom is famous for being a full-featured yet extremely lightweight blogging system—it consists of about 150 lines of perl code. One of the ways that it achieves such simplicity is that it uses the file system as the database—in other words, each entry is saved as a separate text file.

Blojsom picks up where Bloxsom leaves off—it’s written in Java, not Perl, and it adds a number of extra—useful—features. But, crucially, it still uses the file system as the database.

And now I want to talk about yet another feature of Tiger: Spotlight (don’t worry, this is actually going somewhere).

Spotlight is really two things: the first is very powerful tool in the Finder for finding files—using a combination of metadata and full-content searches to return its results—and the second is a set of programming interfaces to the searching technology behind Spotlight. It’s similar to the way that Safari is both a web browser (“Safari”) and the system-level HTML rendering code (“WebCore”).

Before I lose you with too many buzzwords, let’s look at what metadata is. As the name implies, it’s data about data. It’s really simpler than it sounds. It’s information abut an object, but not the object itself. Metadata associated with a generic file might include the date it was created, the kind of file it is (application or data), what applications can open it, the icon that should be used to represent the file, and so on. But metadata can also apply to things other than files: for example, the metadata for an email would include things like the date, the sender, the recipient, the subject, if it’s been read, if it’s been replied to, and so on.

It’s worth repeating here that much of the metadata for an email and a blog post are the same.

One of the interesting things about Spotlight is that it’s extremely focused on searching and finding files. In fact, in order to take full advantage of the new technology, the next version of Mail.app will change the way it stores mail messages.

At the moment, Mail.app saves email using mbox format: each folder is saved as a file; individual messages are aggregated together inside each file. The version of Mail.app that will ship with 10.4 changes that: now, each email will be saved as a separate file. In other words, they’re letting the file system be the database.

Hm. Sounds familiar, doesn’t it?

I think that one of the key reasons why Apple picked blojsom as the turnkey blogging server for Tiger Server is precisely because the file-oriented nature of it’s storage mechanism fits perfectly with the way that Spotlight is designed.

So now the question is how exactly will Spotlight be integrated into the blogging server? The obvious answer is that it can be used as an ultra-fast site search function. But it could also easily automate finding similarly related posts—kind of an automated category-building feature. Something like that might go a long way towards solving some of the problems I talk about here.

Other uses? I’m not entirely sure, to be honest. But the combination of such a powerful search tool and blogging is sure to generate new and innovative applications—the sort of thing that’ll be blindingly obvious, but only after someone invents it. Anyone have any ideas?