Manas Tungare

The query: Protocol

Update: I implemented this idea at http://queryprotocol.appspot.com. Comments, questions, and suggestions are welcome!

When trying to explain a concept to others over email, I often find myself linking to a search engine’s result pages for a specific query, instead of a single destination URL. These are non-navigational queries, and there is no single result that I expect to be the most important one. Instead, my intention is to provide the reader a variety of links on the topic such that s/he may draw her own conclusions, or solve their own problem — all they need is a nudge towards the right query term to use. If, over time, better search results are available for the same query, then future readers get the benefit of automatically updated results.

E.g. Q: Where can I find the latest numbers related to the spread of the Swine Flu?
A: Try [H1N1 update].

To do this today, I simply link to my favorite search engine, Google. But that does not seem fair to fans of other search engines: Bing, Yahoo!, Altavista, and others. I would prefer to use a notation that allows the reader to use their choice of search engine to obtain the results. Just as we specify our default browser and default email client, we should be able to pick our default search engine.

We have already solved the first two problems (picking default browsers and email clients) using protocol handlers in the operating system. When I pass around a link to a web page, starting with http://, I do not specify the browser it should open in. Your operating system determines that it’s a link to a hyper-text transfer protocol (HTTP) document, and invokes your default browser. Similarly, for emails, the mailto: protocol provides for an application-agnostic way to invoke the user’s default email client to send an email.

It is easy to see how a query: protocol could be implemented similarly. To point you to the search results for a particular term, I would send you the following link: (don’t click on it, it won’t work — at least as of this writing.)

[h1n1 update]

The URL that the above links to is query:h1n1+update. Note there’s no HTTP protocol marker specified. If the OS wanted, it could provide local results as well. This means that the protocol extends seamlessly to Desktop Search as well.

Syntactically, this validates as a URI. Just as the mailto: protocol handler defines standard parameter names, subject, cc, and bcc, similar parameters can be standardized for the query: protocol. These may include corpus restricts (corpus={web, images, desktop, ...}), pagination controls (start=0, num=10), or domain restricts (site=manas.tungare.name).

Implementation is simple: all operating systems and major browsers support external custom protocol handlers. They can be configured as follows:

Protocol Prefix: query
Application Name: /Path/to/Application

The application does not need to be very complicated. It’s a mere stub, which, depending upon the user’s preferred search engine, converts a URI of the form query:h1n1+update to http://google.com/search?q=h1n1+update or http://bing.com/search?q=h1n1+update and opens that link in the user’s default browser.

Eventually, if browsers understand the query: protocol, there is no need for the stub application, and users may be able to share and exchange queries and yet seek results using their favorite search engines.

(The opinions expressed in this blog post are solely my own, and may not reflect the opinions of my employer, Google.)

Comments

  1. This is a great thesis. I recently got my Wave sandbox and already built a robot that formats code in a live manner – the prospect of having something happening live and as a result of an entity theoretically equal to other users is very interesting; funnily enough i was also thinking about making a robot connected to search somehow, so, having read your post, what would be simpler and cooler than to specify the query as [my query] and have the robot simply link to the search page. I’m curious if you see any enhancements to this view (or what would help users even more) in the Wave medium.

    Teo — September 1, 2009

  2. Very interesting, Manas. And, very practical and useful too. When will this be available :)

    Uma — September 1, 2009

  3. Genius!! :) how do you come up with these things ?

    Supriya — September 2, 2009

  4. Great idea Manas! More details about external protocol handlers in the most popular OSs and browsers would be great – particularly all the regedit mumbo-jumbo that’s required to register an external protocol handler for IE. Like it or not your target audience would be largely on some form of IE.

    Aditya Gore — September 2, 2009

  5. @Teo: Sounds great, go for it! I can send you brief docs for queryprotocol.appspot.com, it can parse and redirect your queries to any search engine. And it’s hosted on AppEngine, so it won’t run out of bandwidth/CPU anytime soon.

    @Uma: It’s available today! I wrote up an implementation last night.

    @Aditya: Here’s how: http ://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx. Too bad I don’t have a working Windows + Visual Studio installation, otherwise it’s a 4 hour job to write a small app that does this.

    The last time I tried to setup a Windows box to fix a bug in an older app, it took me two days to get the VM running (WinXP + VS). Then I added 20 GB to the VM disk, and Windows decided I was pirating it and shut me off. I had neither the time nor patience to deal with a Microsoft phone call, so I deleted the ^%^$%@#% VM image and went back to my Mac.

    Manas — September 2, 2009

  6. I found this http://opensimulator.org/wiki/Browser_Protocol_Handler interesting. You should be able to flick the registry munger from there and modify that without too much hassle.

    Aditya Gore — September 3, 2009

  7. AJ — September 3, 2009

Leave a comment

 

Popular Posts