The query: Protocol
Sep 01, 2009
Update: I implemented this idea at https://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 https://, 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.)
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 https://google.com/search?q=h1n1+update or https://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.)
