Bug 16030 - Add support for OpenSearch to WebCore with an API usable by various ports
Summary: Add support for OpenSearch to WebCore with an API usable by various ports
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Enhancement
Assignee: Nobody
URL: http://www.opensearch.org/Home
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-17 12:16 PST by Ryan Leavengood
Modified: 2008-06-09 06:54 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Leavengood 2007-11-17 12:16:55 PST
One thing I was wondering recently is if anyone is working on OpenSearch support
in WebKit? This is how the Firefox "Search Engines" are implemented, and IE7
also supports this. See http://www.opensearch.org/Home

I think this would be a useful addition to WebKit and having a nice API for it
would allow all platforms to easily use it in their browsers.

What I envision is an OpenSearchXML class which can parse the OpenSearch XML format, loading either from a URL, file or string, and can then have accessors for the various data elements in the format (ShortName, Description, Url, etc.) In addition a method can be provided to compose a "filled-in" URL based on what the user's search string was.

Support can also be added for the <link rel="search" /> tag described in the OpenSearch specification. When WebCore parses this a new method in ChromeClient could be called with the URL of the XML document with the search specification. This can be used to implement a similar feature to what Firefox does by "highlighting" the search drop-down next to its search box when it sees an OpenSearch link in the document. Try going to Wikipedia or other search sites with Firefox and you will see what I mean.

I am not sure to what level the WebKit team would want to integrate this, but I suppose it could be implemented like the icon database where WebKit even stores the data for the search engines (either in their native XML or maybe some proprietary format in SQLite.)

If no one else takes this on, I will probably do it, at least one my Haiku port of WebKit is in good shape.
Comment 1 Mark Rowe (bdash) 2007-11-17 13:18:14 PST
This may be something that a web browser would like to support, but I don't think it makes sense for WebKit to provide it.  There is nothing about the specification that requires WebCore-level integration, so in this instance I think it would make sense to be implemented as a separate WebKit-using library rather than as part of WebKit itself.
Comment 2 Ryan Leavengood 2007-11-17 14:29:16 PST
(In reply to comment #1)
> This may be something that a web browser would like to support, but I don't
> think it makes sense for WebKit to provide it.

Yeah that was kind of my first thought too. But I figured if someone (like myself) did the work, adding it to WebKit would make it easier for other ports to use it. With Firefox and even IE7 supporting it, I think it is becoming a de facto standard for specifying how to search with a given service.

> There is nothing about the
> specification that requires WebCore-level integration, 

Will the HTML parser show <link rel="search" /> tags in the DOM? In other words if the engine doesn't directly support a "callback" when it finds those tags, will the browser be able to look over the DOM and find them? I am not yet familiar with that part of the WebKit code and don't know if "unknown tags" are not put in the DOM.

> so in this instance I
> think it would make sense to be implemented as a separate WebKit-using library
> rather than as part of WebKit itself.

Is there any precedent for libraries that build on top of WebKit like this? How would other WebKit developers find such libraries? Is there a place to register them so others can find them?

Because I think this idea is fine, but it would be nice if there was an infrastructure for it.
Comment 3 Mark Rowe (bdash) 2007-11-17 15:39:30 PST
(In reply to comment #2)
> (In reply to comment #1)
> > This may be something that a web browser would like to support, but I don't
> > think it makes sense for WebKit to provide it.
> 
> Yeah that was kind of my first thought too. But I figured if someone (like
> myself) did the work, adding it to WebKit would make it easier for other ports
> to use it. With Firefox and even IE7 supporting it, I think it is becoming a de
> facto standard for specifying how to search with a given service.

That's fine, but Firefox and IE are both browsers.  Adding support to WebKit-using browsers such as Safari, OmniWeb or Epiphany does not require adding support to WebKit.

> > There is nothing about the
> > specification that requires WebCore-level integration, 
> 
> Will the HTML parser show <link rel="search" /> tags in the DOM? In other words
> if the engine doesn't directly support a "callback" when it finds those tags,
> will the browser be able to look over the DOM and find them? I am not yet
> familiar with that part of the WebKit code and don't know if "unknown tags" are
> not put in the DOM.

Unknown tags remain in the DOM, yes.  In this case however, "link" is a standard element specified in HTML 4: http://www.w3.org/TR/html401/struct/links.html#h-12.3.

> > so in this instance I
> > think it would make sense to be implemented as a separate WebKit-using library
> > rather than as part of WebKit itself.
> 
> Is there any precedent for libraries that build on top of WebKit like this? How
> would other WebKit developers find such libraries? Is there a place to register
> them so others can find them?
> 
> Because I think this idea is fine, but it would be nice if there was an
> infrastructure for it.

I don't think such a library would be particularly WebKit-specific.  Extracting the relevant "link" elements from the DOM is clearly WebKit specific but would be a relatively small amount of code (maybe 100 lines, if that).  The real work would be in the parsing of the OpenSearch description document, the URL templates, and response formats.  None of this needs to be WebKit-specific.  In my opinion it would benefit a wider audience if this code was *not* WebKit-specific.
Comment 4 Ryan Leavengood 2007-11-17 15:48:05 PST
I agree with Mark's assessment, and if I decide to implement this one day, I will make it a generic library with easy WebKit integration.