Last week I mentioned Greasemonkey , a Firefox extension that enables scripts to run in the context of Web pages. Since then I've written a few of my own Greasemonkey
scripts. The first, which I've shown in a screencast, is an improved LibraryLookup.
With the original, you had to click a bookmarklet to jump from an Amazon page to a book's record in your local library. Now,
if the book is available in the library, the Greasemonkey script automatically inserts an alert into the Amazon page.
As I discussed in the screencast, page rewriting is a hot topic that's about to go nuclear. When Google's toolbar added an
AutoLink feature that can turn postal addresses and ISBN numbers into links, it rekindled the debate that forced Microsoft
to withdraw its similar Smart Tags feature several years ago.
The issues are complex. When a page that doesn't link to Google Maps or to Amazon is modified to do so, the alteration touches
on the interests of three parties: the author of the page, the reader, and the proprietor of the service to which the link
points. From the author's perspective, an altered page can be seen as a copyright-violating derivative work. From the reader's
perspective, it might be seen as deception, which is why AutoLink must be explicitly invoked each time it's used. From the
service provider's perspective, it's great -- so long as the provider's service is the link destination; otherwise, it's not
so great.
My new LibraryLookup script touches on the same set of interests, albeit in slightly different ways. In this case, Amazon
is both the author of the content and the provider of the service. Notification of an alternate service, when available, benefits
the reader and nobody else.
It's hard enough to think about this puzzle in terms of content. It gets even harder as content and services intermingle.
Here's a message I hope I never see, but fear I might: “Service unavailable. Your browser does not support DOM locking.”
I'll let the lawyers chew on that one. Meanwhile, let's focus on how this technology can deliver the kinds of dashboard views
that make hearts flutter in the enterprise. Until recently, I've used a couple of bookmarklets to gauge reaction to my InfoWorld articles, based on the list of del.icio.us bookmarks pointing to an article and the Bloglines summary of citations. Now,
instead, I have a Greasemonkey script that counts these things and injects the counts into the InfoWorld pages I read.
You'd think these extra requests would slow things down. But because they're asynchronous, they don't. The script just fires
off requests. When (or if) answers come back, it interpolates them into the page. Two components make this possible. One is
the scriptable DOM, which enables in-situ alteration of Web pages. The other is the XMLHttpRequest object, which is now available
in all the major browsers and which supports asynchronous interaction with remote services.
Combine the two and you get a powerful system for delivering real-time alerts in the context of Web pages. AJAX (Asynchronous
JavaScript and XML) is the new name for this strategy, but it's an old idea, and XML is optional. At its core, this is about
Web pages that communicate autonomously and update themselves dynamically. You'll soon see a lot more of these, and you may
well find yourself creating some, too.