[3358] in Release_7.7_team
Netscape 6 Athena Status Report
daemon@ATHENA.MIT.EDU (t. belton)
Mon Jun 24 13:28:06 2002
Date: Mon, 24 Jun 2002 13:28:02 -0400 (EDT)
From: "t. belton" <tbelton@MIT.EDU>
To: <release-team@mit.edu>, <netscape-release@mit.edu>
cc: <thg@mit.edu>
Message-ID: <Pine.GSO.4.30L.0206241303510.19327-100000@iphigenia.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
[I've sent this to release-team so they'll have it for Wednesday, to
netscape-release for obvious reasons, and to thg because my bosses like to
know what I'm doing :) If there are any other lists or humans you think
should see this, by all means pass it along. -t]
Here's a summary of the various problems we've had with getting Unix
versions of Netscape 6 to work in a locker, and the solutions to same. I
am happy to report that most of the problems, at this time, DO have
solutions; there is only one issue left on the list which is still
unsolved, although most of the solutions aren't fully implemented yet.
The problems can be broken down like this:
1. Massive differences in the way the Sun version (maintained by Sun) and
the Linux version (maintained by Linux) do business.
2. Many dialogs and other nuisances, like stdout spam while running, which
needed to be circumvented/disabled, especially on 1st run when Netscape
tries to generate/convert a set of user prefs.
3. Difficulties getting Netscape to find plugins, especially Java which
seems to have a hard-coded path that is dependent on where you originally
installed the product.
4. Problems getting Netscape to properly read and store the preferences WE
want, especially in the Sun version, which seems to ignore or lock out a
number of them.
5. The Mozilla random prefs directory. This "security feature" is a
randomly-generated directory name where user prefs are stored; eight
alphnumerics, a dot, and 'slt'. Since this name is unknown to a global
script, it makes changing user prefs (i.e. from netscape-fix or
equivalent) more difficult, and it makes generating an initial user prefs
file from scratch just about impossible. (We can't generate our own bogus
random name, because there is a small binary registry file containing that
name whose format we haven't cracked. Netscape has to generate the
directory itself.
Last first. #5 has been solved. In fact, it should have occurred to me
sooner; looking for regexps in directory names is trivial in Perl, and
netscape-fix is a Perl script already. Since there will only ever be one
????????.slt directory under the user's name in the .mozilla hierarchy,
and we can get the user name from $USER (which is where Netscape got it to
write the hierarchy in the first place), all is well. (We will not be able
to fix any alternate profiles the user has created, but we don't expect
many Unix users to take advantage of the multiple-profiles system
anyway.)
As for making the user prefs in the first place, we are going to let
Netscape do that. Some research, including Bill picking brains at Mozilla
(thanks, Bill) has determined the correct set of global files to modify.
If we change these global prefs, then when Netscape generates the user
prefs it will generate them the way WE want them anyhow. No need to
circumvent the local-prefs-making process at all. We hope.
These global settings should also allow us to turn off all of Netscape's
minor annoyances, though I'm still researching all the various settings I
need. So that solves #2 and #4 as well. And with any luck, it'll go a long
way toward solving #1.
That leaves the plugin paths. Frankly, one of the problems is - without
actually documenting this anywhere - apparently Mozilla doesn't look at
the old NPX_PLUGIN_PATH variable at all. This leaves us with no good way
to specify a search path for plugins. Bill has suggested CLASSPATH and I
will try that shortly. I am also going to go back to Mozilla for more on
this.
With the vital and tricky Java plugin, we've "solved" the Sun problem by
simply giving it what it wants - physically putting the proper plugin back
in the location it expected, in Netscape's 'components' directory. It will
not look for it anywhere else, not even in netscape/plugins. On the other
hand, the Sun Netscape only seems to run well with a single specific
version of the plugin, so linking to the latest version in the Java locker
(my preferred solution) didn't work anyway.
The Linux version is still looking for that plugin in /var/todd, the
original installer path, and I can't find or change that string for love
nor money. Unless we can override this with an environment variable we
haven't found yet, I may have to reinstall the Linux version to get around
this. That's the last major unsolved.
I'm not making any time estimates on getting these solutions finished and
applied. I've made bad estimates twice on this project and I'm not falling
for it again. They will be done as quickly as they can be done.
-Todd
