Mozilla looks to simplify embedding [LWN.net]

By Jake Edge
May 21, 2008

There has been a longstanding complaint about the difficulty in embedding Mozilla into other applications, but an effort is underway to change that. Mozilla evangelist Christopher Blizzard is coordinating a group of interested developers to redefine the application programming interfaces (APIs), libraries, and embedding "story" to try to make it easier for other applications. Mozilla is leading the way, but they want to build a community around embedding, so they are reaching out to developers that wish to help guide the effort.

Embedding the Gecko rendering engine—the guts of Mozilla's web content handling—will allow separate programs to deal with and use the web without writing the code themselves. New applications can leverage all of the work done by Mozilla to handle HTML, CSS, Javascript, etc. to concentrate on their specific task. There are several embedding use cases cited on the Mozilla wiki, but the focus of this new effort has been on applications where handling web content is just part of the task at hand.

To some extent, this effort is probably being driven by the rise of WebKit, which has a specific focus on being embeddable. WebKit is derived from the KHTML rendering engine—which underlies Konqueror—as modified by Apple for their Safari browser. There has been a fair amount of press about WebKit lately, which, along with the defection of the Epiphany browser from Gecko to WebKit, may have given Mozilla more motivation to make Gecko more embeddable.

Two meetings have occurred so far to discuss and plan a strategy for providing better embedding support. Blizzard has a lengthy report from the first which goes into some detail about the direction they are headed. The other was held in early May, but there are no reports from that as yet. This a young project that is looking for more interested folks to get involved.

One of the larger complaints about trying to embed Gecko into other applications is that there are multiple ways to do it. It is difficult for a developer to know which is right for their application. Blizzard says:

Sometimes you use libxul, sometimes you use the win32 embedding widget, sometimes you use the gtk embedding widget, sometimes you have to reach down into internal interfaces to change things and some times you don't. Having a single story around how to make use of the embedding APIs on your platform and in your environment is one of our goals.

Another area that needs work is providing a stable API. One of the downsides to not having stability at the API or application binary interface (ABI) is that security holes in Gecko tend to cascade throughout all the other applications that use it. But Blizzard does not expect to nail down the API right away:

So we will have some iteration during early development and will start locking things down once we have a better sense of what people [want] and what we'll need to change internally once we understand about our user's specific use cases. Stable API is a goal, but it's a longer goal. The more that we have people help us understand and contribute code out of the gate the faster we will get here.

The diagram at right gives an overview of how the new API will fit. There is existing code at both the top and bottom of the diagram, while most the of the middle is new. Applications will be able to use some of the embedded functionality through platform-specific APIs—for GNOME, Windows, or OS X—or write directly to the new embedding APIs for more capabilities. One of the more interesting decisions is to use the existing APIs as a model, but not for creating a fully compatible implementation. Blizzard explains:

Note that trying to be a drop in replacement to WebKit or MSHTML/WebBrowser Control is not on the table. Therein lies madness. You end up chasing compatibility instead of just trying to make something that works really really well. But we can learn what works well from them and what doesn't and hopefully apply that to our new embedding interfaces.

The project has started on a roadmap of features that need to be worked on, beginning with the basics. Reorganizing the libraries and header files to create a software development kit (SDK) is high on that list. One of the bigger issues that needs to be addressed is how to handle profiles—the directory (i.e. $HOME/.mozilla) that Mozilla uses for user-specific data storage. Some use cases will want to run without a profile, but the current code expects to always have one available. The full list in the meeting report is worth a read.

This is an interesting project that should lead to more interesting applications down the road. The barriers to working with Gecko today are fairly high, but the advantages to using a well-tested, well-supported, and reasonably fast rendering engine for applications that need it are compelling. Those barriers look to be lowering in the not-too-distant future.

(Log in to post comments)