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
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
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
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
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.
to post comments)