The GRE and you.

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

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

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

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

http://www.mozilla.org/projects/embedding/MRE.html

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

http://bugzilla.mozilla.org/show_bug.cgi?id=3D185681

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

http://bugzilla.mozilla.org/show_bug.cgi?id=3D173262

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

http://bugzilla.mozilla.org/show_bug.cgi?id=3D183075

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

http://bugzilla.mozilla.org/show_bug.cgi?id=3D186241


Please send me feedback directly or comment in the bugs.


Thanks,

Doug Turner
[email protected]