Gecko Runtime Environment Overview

by DOUG TURNER | This includes an overview of some of the work that Chak, ssu, curt, and I have been doing. I wanted to get some feedback about both the general direction and actual implementation. This work is regarding the Gecko Runtime Environment. In the not so near future, there will be GRE's sitting on endusers' machines. In fact, you can download a GRE from today. I would like to start letting the Mozilla client start using the GRE if it is installed and eventually install the GRE with the Mozilla client.

Before doing all of this there are few parts to this discussion that I would like feedback for.

First I would like feedback on how we are going to find a GRE? (Note that this is just the default behavior. Embedders can code up anything they like — they can choose to use a private copy of the GRE shared only between 'their' gecko applications or they can choose a different search order, etc.) The basic idea is an embedding application starts up, it looks around for where the GRE is, then it sets up its load library paths, finally it dynamically loads XPCOM. From this point, everything else that embedders have been doing is exactly the same.

Currently, on windows, we store where a GRE is installed in the Windows Registry file. On nix, I have a patch with will store the equivalent information in /etc/gre.conf (if you have other places I should check, please let me know). So that a user can run against a local GRE, I was thinking about offering a $(HOME)/.gre.config file which would be checked first. The Windows work (as well as a broad description of the GRE) is described here:

I wrapped up all of the necessary loading logic into a library so that it is easy for embedders to actually startup Gecko. This bug describes (in code) exactly what the format of the gre.conf file is. The format is really simple and extensible. This work is being done here:

The next idea that I wanted discussed was converting the Mozilla application (and also, viewer and other embedding applications) to use the MRE if present. What I am going to do is make the Mozilla app use the default startup code I mentioned above. I have prototyped this work, and for the most part everything seams to work fine. When everything is nailed down, I will post a patch to his bug:

I would like to also change some of the testing tools. Specifically, I am going to make RegXPCOM a lot better. It will no longer be tied to a release, i.e. you will be able to have a copy of RegXPCOM in your bin/ directory if you wanted. This work is here:

The next thing is how the GRE is built and delievered. I have asked Chris Seawood to add explicit supported for the GRE in the makefiles. This is similar to what we did to support the SDK exports. Basically, there will not be a separate packaging step to bundle the GRE. It will be built in mozilla/dist/gre. For the time being, files will be mirrored into dist/bin. However, at some point in the future, I would like to see dist/bin going away and instead a mozilla/dist/<app>, where app is the directory that contains the current application your building. This may be Phoenix, the Mozilla client, etc. (Details haven't be worked out for how this is going to work, but the general direction is that you pull or build the GRE and then build an application on top of it.) The work that Chris is doing is being tracked here:

Please send me feedback directly or comment in the bugs.


Doug Turner

Got a response? TalkBack!


MozillaZine and the MozillaZine Logo Copyright © 1998-2002 MozillaZine. All Rights Reserved.
Privacy Policy