[25415] in Athena Bugs
Re: mozilla plugin path overrides?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jan 10 18:52:18 2004
From: Greg Hudson <ghudson@mit.edu>
To: John Hawkinson <jhawk@mit.edu>
In-Reply-To: <200401102342.i0ANgMDh016888@coleco-sidewinder.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1073778726.32657.331.camel@error-messages.mit.edu>
Mime-Version: 1.0
Date: Sat, 10 Jan 2004 18:52:07 -0500
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
On Sat, 2004-01-10 at 18:42, John Hawkinson wrote:
> (Incidently, why are the mozilla plugins still in AFS? Are there not
> performance issues?)
Well, there was a performance issue with Java, because it's big and
involves many files. But the Flash plugin isn't so big; I don't think
it's a big performance issue.
> I doubt there are many people who set MOZ_PLUGIN_PATH and expect it to
> be appeneded to, so I doubt many would suffer.
I do this, in order to get a newer flash plugin than the one we have
installed. Obviously, I'm not concerned about my own welfare, but
anyone who followed the same thought process will have done the same
thing.
A more backwards-compatible, if less elegant solution, would be to
invent a new variable name (MOZ_FULL_PLUGIN_PATH or something), and have
it override the plugin path computed by the wrapper script if it's set.
> p.s.: Arguably it's better to have all the plugins symlinked from
> $HOME/.mozilla/plugins (though an @sys indirection, I guess), so
> that users can decide which plugins they want all by themselves,
> instead of being forced to accept the system plugins. I guess that
> might make it more awkward to add a new plugin systemwide, though,
> but it could be handled.
Could be handled how?
