Making extensions available to multiple GRE applications
Benjamin Smedberg
GRE, and I would like to outline my plans for GRE extensions (and
extensions in general) so that people may comment. Please reply to
n.p.m.xpinstall, and not to the bugs, unless you have a patch or
implementation comment. The overarching bug is bug 209439.
Definitions:
"extension" == a browser addon or utility (installed with XPInstall)
My plan has the following goals:
1) allow extensions to be registered with a GRE, so that they can be
made available to multiple applications using the GRE
2) allow extensions to be installed into their own directories, instead
of being installed in the same directory as an application
3) allow extensions (which use only frozen interfaces) to work with
multiple versions of the GRE
4) allow extensions to be un-installed
Currently, extensions "piggyback" on top of an application's chrome and
components directories. This makes it difficult/impossible to un-install
extensions. Instead, it should not be difficult for extensions to
maintain their own chrome and components locations.
Implementation-prerequisites:
1) The chrome: service needs to be extended to register arbitrary chrome
directories (bug 210838)
Implementation:
Each extension would have an RDF file describing itself. The GRE would
include an nsIExtensionManager service, which would allow applications
to enumerate/discover available extensions, register extensions, and
enable/disable extensions as necessary. The GRE would not contain any UI
for extensions; any UI would be managed by applications. There would
also be a little command-line utility with the GRE that would register
extensions.
Extensions would not be enabled by default; instead, after the
application initializes the GRE, it would need to use the
nsIExtensionManager to enable the extensions that it wished to use.
Although every extension could use this mechanism, extensions meant for
multiple applications would benefit most from this scheme. Some
important examples would include:
DOM Inspector
Venkman
JSLib
tranformiix
I feel that GRE extensions are necessary, in order for the new roadmap
to be implemented effectively.
--BDS
P.S. Can I also argue that there ought to be a second alpha before
1.5beta? Not much of the current roadmap has been completed yet, and
we're going to freeze 1.5a on Wednesday... how about another month and
then 1.5a2?
Sailfish
> I have filed and taken several bugs having to do with extensions and the
> GRE, and I would like to outline my plans for GRE extensions (and
> extensions in general) so that people may comment. Please reply to
> n.p.m.xpinstall, and not to the bugs, unless you have a patch or
> implementation comment. The overarching bug is bug 209439.
>
> Definitions:
> "extension" == a browser addon or utility (installed with XPInstall)
>
> My plan has the following goals:
>
> 1) allow extensions to be registered with a GRE, so that they can be
> made available to multiple applications using the GRE
> 2) allow extensions to be installed into their own directories, instead
> of being installed in the same directory as an application
Is your plan to allow them to be installed in an arbitrary directory or
would they still need to be off a chrome root (installation/profile)?
--
Netscape FAQs: http://www.ufaq.org/
Netscape 6/7 Tips: http://www.holgermetzger.de/net6e.html
Netscape 6 FAQ: http://home.adelphia.net/~sremick/ns6faq.html
Netscape 7 Help/Tips: http://techaholic.net/ns7.html
Web page validation: http://validator.w3.org
About Mozilla: http://www.mozilla.org
Benjamin Smedberg
> would they still need to be off a chrome root (installation/profile)?
New-style extensions would install in arbitrary locations, which would
*always* be outside a chrome root. For example, JSlib might install
itself (on win32) in "C:\Program Files\Common Data\mozdev.org\JSlib\1.1"
or something like that. (Old-style extensions that don't know about this
new extension scheme would still install themselves in the application
chrome/components directories).
--BDS
Sailfish
XPI to add (replace?) files outside of the Mozilla domain like, say,
into the Windows directory?
Kjetil Wikestad
Hyatt wrote something about changing the extension interface in Firebird
(http://weblogs.mozillazine.org/dave/archives/2003_06.html#003557), he
also got a lot of comments.
You should really coordinate your work with him so that Firebird don't
get one implementation and GRE a different one. Actually, you should
decide where it is best to keep different extensions before going any
further.
--
Kjetil W.
Benjamin Smedberg
> XPI to add (replace?) files outside of the Mozilla domain like, say,
> into the Windows directory?
As I understand it, XPIs can currently install files anywhere they like.
Kjetil Wikestad
You should really visit Hyatt's blog. He have a entry where he discuss
the future implementation of extensions in Firebird.
http://weblogs.mozillazine.org/dave/archives/2003_06.html#003557
In my opinion there should exist a consensus about the types of
extensions possible in Firebird/GRE and where to put those extensions.
There should not be one implementation in the GRE and a different
implementation in Firebird.
--
Kjetil W.
Brian 'netdemon' Bober
said in the bugs that we can't allow hooks into particular features
(scrolling, etc) without significant internal modifications.... But we
can still allow extensions based on C/C++/XPCOM as long as they aren't
extending a portion of the toolkit that could only be extended through
modifying our internal code, right?
Benjamin Smedberg
> said in the bugs that we can't allow hooks into particular features
> (scrolling, etc) without significant internal modifications.... But we
> can still allow extensions based on C/C++/XPCOM as long as they aren't
> extending a portion of the toolkit that could only be extended through
> modifying our internal code, right?
Yes, extensions can be written in any language (even Python, if you have
PyXPCOM). Theoretically they can do large-scale changes to core GRE
services by registering for important contractIDs (for example, adding
extra functionality to the ioservice).
--BDS