Component Registry
This commit is contained in:
dp%netscape.com
Родитель
1a462db603
Коммит
ba8cba6747
|
|
@ -3,7 +3,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
||||
<meta name="Author" content="Suresh Duddi">
|
||||
<meta name="GENERATOR" content="Mozilla/4.51 [en] (WinNT; U) [Netscape]">
|
||||
<meta name="GENERATOR" content="Mozilla/4.51 [en] (X11; U; Linux 2.0.36 i686) [Netscape]">
|
||||
<title>XPCOM Dynamic Component Registration</title>
|
||||
</head>
|
||||
<body>
|
||||
|
|
@ -19,7 +19,7 @@ XPCOM Dynamic Component Registration</h2></center>
|
|||
following components:
|
||||
<ul>
|
||||
<li>
|
||||
The Registry</li>
|
||||
The Component Registry</li>
|
||||
|
||||
<li>
|
||||
The Repository</li>
|
||||
|
|
@ -35,9 +35,129 @@ to that of COM. The XPCOM component dlls will have the opportunity to register
|
|||
themselves with the registry. The exact time of installation would be either
|
||||
at install time or as a result of <b>autodetection</b> by the Repository
|
||||
Manager at runtime.
|
||||
<br>
|
||||
<br>
|
||||
<hr WIDTH="100%">
|
||||
<h3>
|
||||
<a NAME="The Registry: XPCOM Hierarchy"></a>The Registry: XPCOM Hierarchy</h3>
|
||||
<a NAME="The Registry: XPCOM Hierarchy"></a>The Component Registry</h3>
|
||||
There are three types of Component Registries:
|
||||
<ol>
|
||||
<li>
|
||||
<b>App-Component-Registry<br>
|
||||
</b>Each application has its own Component Registry that lives along with
|
||||
the app in its <exe-dir>/components directory. The Component Registry
|
||||
is created on installation or first run. It is be used read-only by XPCOM</li>
|
||||
|
||||
<li>
|
||||
<b>User-Component-Registry</b></li>
|
||||
|
||||
<br>Each user can install additional components under their user home directory.
|
||||
These components will be shared across all XPCOM applications that the
|
||||
user runs.
|
||||
<li>
|
||||
<b>Meta-Component-Registry</b></li>
|
||||
|
||||
<br>Sharing Components between application: This can happen in two ways.
|
||||
The installer of an application can find the other application's components
|
||||
by looking for the application specifically and registering them with this
|
||||
app's component registry. The second and more preferable approach is to
|
||||
keep a machine wide Meta-Components-Registry that would aggregate all the
|
||||
app component registries.</ol>
|
||||
The difference component registries will be searched in the following order:
|
||||
<ol>
|
||||
<li>
|
||||
User Components Registry</li>
|
||||
|
||||
<li>
|
||||
App Component Registry</li>
|
||||
|
||||
<li>
|
||||
Meta Component Registry</li>
|
||||
</ol>
|
||||
The user component registry is the only one that will be updated on the
|
||||
fly by XPCOM. JS will be given the option to update either the App-Component-Registry
|
||||
or the User-Component-Registry and this may succeed fail based on write
|
||||
permission, although the general guideline is to update the User-Component-Registry.
|
||||
JS will have to do special things to update the App-Component-Registry.
|
||||
<p>Profiles are a notion of the app (navigator) and xpcom has nothing to
|
||||
do with it. The app will store app specific data in a Data-Registry that
|
||||
will be stored under the user's home directory.
|
||||
<h4>
|
||||
How does this Solve our problems</h4>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
Multiple installations of mozilla and xpcom based apps</li>
|
||||
|
||||
<br>Since each installation is going run with their own App-Component-Registry,
|
||||
basically both apps will work. No inter process locking is essential. Since
|
||||
both processes will operate on the User-Component-Registry, inter process
|
||||
locking of the User-Component-Registry will be required.
|
||||
<li>
|
||||
Third Party components installation</li>
|
||||
|
||||
<br>Third parties can install components in their own directories and update
|
||||
the App-Component-Registry (preferable) or User-Component-Registry depending
|
||||
on if the sharing of component needs to be specific to the user or for
|
||||
all users. Facilities for updating the registry would be to use JS or write
|
||||
XPCOM code in their installer. The other option would be to add their components
|
||||
in their own directory, create a App-Component-Registry of their own in
|
||||
their directory and reference it in the Global Meta-Components-Registry.
|
||||
This will get their components used by all applications.
|
||||
<li>
|
||||
Registry used to store app specific data</li>
|
||||
|
||||
<br>This is a totally separate registry: the Data-Registry. The theory
|
||||
is that this will reside in the user's home directory. The registry hierarchy
|
||||
is app specific.
|
||||
<li>
|
||||
User Specific components</li>
|
||||
|
||||
<br>This is basically the User-Component-Registry. Inter process locking
|
||||
is required as all processes with XPCOM will access the same User-Component-Registry.
|
||||
<li>
|
||||
Embedding</li>
|
||||
|
||||
<br>This is requires more thought. The fact is when say Gecko is embedded
|
||||
into an application, Gecko is running most probably in the process space
|
||||
of that application and hence the XPCOM used will look for components in
|
||||
this embedding applications directory. The embedding procedure should create
|
||||
a App-Component-Reqistry for the embedding application that should contain
|
||||
all the components from different apps this app would like to use. This
|
||||
is however not required, if the Meta-Component-Registry exists.
|
||||
<li>
|
||||
User not having permission to the place where the global registry lives,
|
||||
if there is one.</li>
|
||||
|
||||
<br>First the App-Component-Registry is written to only when there is a
|
||||
new component or a component has gone away. New components come with installers
|
||||
or the user calls regFactory.exe with the dll as an argument or clicks
|
||||
on a button that says "refresh my user components" which will cause autoregistration
|
||||
of user components. For deleted app components, annotations will be made
|
||||
in the User-Component-Registry. Deleted user components is a non-issue.
|
||||
<li>
|
||||
NFS mounted home directories and app directories</li>
|
||||
|
||||
<br>NFS mounted home directories requires inter-machine locking of the
|
||||
User-Component-Registry. NFS mounted app directories dont have a
|
||||
problem as the App-Component-Registry is only used read-only by XPCOM.</ol>
|
||||
So in summary,
|
||||
<ul>
|
||||
<li>
|
||||
App-Component-Registry pretty much solves the top problem of Multiple applications.
|
||||
With some help from the installer, Third party components will also be
|
||||
solved.</li>
|
||||
|
||||
<li>
|
||||
User-Component-Registry solves the User Specific Components problem.</li>
|
||||
|
||||
<li>
|
||||
Meta-Component-Registry enables the dynamic sharing of components between
|
||||
apps which eases embedding.</li>
|
||||
</ul>
|
||||
As a first cut, I am going to implement the App-Component-Registry for
|
||||
M8.
|
||||
<h4>
|
||||
Hierarchy Used by Component Registry</h4>
|
||||
XPCOM uses the nsRegistry to store mappings between CLSIDs and their implementations.
|
||||
The Registry provides persistent storage of hierarchical keys and name-value
|
||||
pairs associated with each key. Each key also keeps a default value.
|
||||
|
|
@ -47,8 +167,7 @@ pairs associated with each key. Each key also keeps a default value.
|
|||
<br><tt> Classes</tt>
|
||||
<br><tt>
|
||||
CLSID</tt>
|
||||
<br><tt>
|
||||
|
||||
<br><tt>
|
||||
<b><font color="#CC0000">{108d75a0-bab5-11d2-96c4-0060b0fb9956}</font></b></tt>
|
||||
<br><tt><nobr>
|
||||
InprocServer (S) = <font color="#CC0000">/home/dp/dist/bin/components/libnfs-protocol.so</font></nobr></tt>
|
||||
|
|
@ -57,8 +176,7 @@ ProgID (S) = <b><font color="#CC0000">
|
|||
<br><tt><nobr>
|
||||
ClassName (S) = <b><font color="#CC0000">NFS Protocol
|
||||
Handler</font></b></nobr></tt>
|
||||
<p><tt>
|
||||
<font color="#CC0000">component://netscape/network-protocol&type=nfs</font></tt>
|
||||
<p><tt> <font color="#CC0000">component://netscape/network-protocol&type=nfs</font></tt>
|
||||
<br><tt><nobr>
|
||||
CLSID (S) = <font color="#CC0000">{108d75a0-bab5-11d2-96c4-0060b0fb9956}</font></nobr></tt>
|
||||
<p><tt><i> </i>Software</tt>
|
||||
|
|
@ -68,8 +186,7 @@ XPCOM</tt>
|
|||
<br><tt>
|
||||
VersionString (S)
|
||||
= <font color="#CC0000">alpha0.20</font></tt>
|
||||
<p><tt>
|
||||
|
||||
<p><tt>
|
||||
<font color="#CC0000">/home/dp/dist/bin/components/libnfs-protocol.so</font></tt>
|
||||
<br><tt>
|
||||
ComponentsCount (Int) = <font color="#CC0000">1</font></tt>
|
||||
|
|
@ -79,28 +196,26 @@ FileSize (Int)
|
|||
<br><tt>
|
||||
LastModTimeStamp (S) = <font color="#CC0000">Wed
|
||||
Feb 24 11:24:06 PST 1999</font></tt>
|
||||
<p><tt><font color="#CC0000">
|
||||
|
||||
<p><tt><font color="#CC0000">
|
||||
</font><font color="#000000">Events</font></tt>
|
||||
<br><tt><font color="#000000">
|
||||
Startup</font></tt>
|
||||
<br><tt><font color="#000000">
|
||||
|
||||
<br><tt><font color="#000000">
|
||||
</font><font color="#CC0000">{108d75a0-bab5-11d2-96c4-0060b0fb9956}</font></tt>
|
||||
<br><tt><font color="#CC0000">
|
||||
{17894983-ab78-8d75-a0bb-511d296c4006}</font></tt>
|
||||
<p><tt><font color="#000000">
|
||||
Shutdown</font></tt>
|
||||
<br><tt><font color="#000000">
|
||||
|
||||
<br><tt><font color="#000000">
|
||||
</font><font color="#CC0000">{748958ea-abab-511d-296c-40060b0fb995}</font></tt>
|
||||
<br><tt><font color="#CC0000">
|
||||
{45617894-983a-b788-d75a-0bab11d296c4}</font></tt>
|
||||
<br> </blockquote>
|
||||
|
||||
<h3>
|
||||
<a NAME="The Repository: Object instance creation"></a>The Repository:
|
||||
Object instance creation</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="The Repository: Object instance creation"></a>The
|
||||
Repository: Object instance creation</h3>
|
||||
All object creation happens via The Repository. <tt>nsIRepository::CreateInstance()</tt>
|
||||
will be the primary way of creation of object instances. The steps in instantiation
|
||||
of an object that implements the IID interface and of class CLSID is as
|
||||
|
|
@ -128,7 +243,8 @@ with a call to <tt>nsIFactory::CreateInstance()</tt>.</li>
|
|||
</ol>
|
||||
|
||||
<h3>
|
||||
<a NAME="The Service Manager"></a>The Service Manager</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="The Service Manager"></a>The Service Manager</h3>
|
||||
All globally created system services are available via the <tt>nsIServiceManager</tt>,
|
||||
including the <tt>nsIRepository</tt> and <tt>nsIRegistry</tt>. Although
|
||||
the <tt>nsIServiceManager</tt> uses the Registry and Repository in the
|
||||
|
|
@ -139,7 +255,8 @@ and <tt>nsIRegistry</tt> instance and registering them specially with the
|
|||
The nsIServiceManager is passed into NSGetFactory() for assisting the DLL
|
||||
in the Factory creation process.
|
||||
<h3>
|
||||
<a NAME="Component Registration"></a>Component Registration</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="Component Registration"></a>Component Registration</h3>
|
||||
Either at installation time of the Component or at times when the XPCOM
|
||||
library autodetect new/changed dlls, component registration is activated.
|
||||
The autodetection happens at startup time of the navigator or via a javascript
|
||||
|
|
@ -164,7 +281,9 @@ The dll is unloaded</li>
|
|||
</ol>
|
||||
|
||||
<h3>
|
||||
<a NAME="Autodetection of Components"></a>Autodetection of Components</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="Autodetection of Components"></a>Autodetection
|
||||
of Components</h3>
|
||||
Autodetection of changed dlls happened by storing the dll's last modified
|
||||
time and its size in the Registry automatically. If either the last modified
|
||||
time stamp or the filesize differs from that stored in the Registry for
|
||||
|
|
@ -180,7 +299,8 @@ dll proceed in this case. There is nothing much that XPCOM library can
|
|||
do to salvage this situation other than warning the user of possible instability
|
||||
and advice a restart upon which the re-registration will happen.
|
||||
<h3>
|
||||
<a NAME="ProgID Spec"></a>ProgID Spec</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="ProgID Spec"></a>ProgID Spec</h3>
|
||||
The general format of ProgIDs is <i><b><font color="#990000">component://</font></b>netscape<b><font color="#990000">/</font></b>compname<b><font color="#990000">?</font></b>var<b><font color="#990000">=</font></b>value<b><font color="#990000">;</font></b>var<b><font color="#990000">=</font></b>value<b><font color="#990000">;</font></b>var<b><font color="#990000">=</font></b>value...</i>
|
||||
<p>Let us consider some more examples:
|
||||
<ol>
|
||||
|
|
@ -234,9 +354,13 @@ specified above. We could extend this
|
|||
<br>mechanism with wildcards, but I dont want to go there yet... :-)
|
||||
<br>
|
||||
<h3>
|
||||
<a NAME="Startup Components"></a>Components created on events</h3>
|
||||
Some dlls have components that want to be created on certain events namely
|
||||
Startup, Shutdown (for now). Example is xpinstall.
|
||||
|
||||
<hr WIDTH="100%"><a NAME="Startup Components"></a>Components created on
|
||||
events</h3>
|
||||
<b><font color="#990000">NOTE: THIS IS NOT BEING DONE. We are going to
|
||||
expect the apps to this themselves by using the registry.</font></b>
|
||||
<p>Some dlls have components that want to be created on certain events
|
||||
namely Startup, Shutdown (for now). Example is xpinstall.
|
||||
<blockquote>RegisterComponentForEvent(..., RegisterationTime when, ...)
|
||||
<br>RegisterFactoryForEvent(..., RegistrationTime when,...)</blockquote>
|
||||
exists for this purpose. When an application wants to Fire the particular
|
||||
|
|
@ -261,7 +385,9 @@ on the same event is not defined. Component dependencies aren't thought
|
|||
of yet.
|
||||
<br>
|
||||
<h3>
|
||||
<a NAME="How will all this help me"></a>How will all this help me</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="How will all this help me"></a>How will all this
|
||||
help me</h3>
|
||||
For Component Developers:
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -289,7 +415,9 @@ NULL, kProtocolIID, &result);</tt>
|
|||
&result);</strike></blockquote>
|
||||
|
||||
<h3>
|
||||
<a NAME="What has happened so far"></a>What has happened so far</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="What has happened so far"></a>What has happened
|
||||
so far</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -304,7 +432,9 @@ nsRepository::ProgIDToCLSID() implemented</li>
|
|||
</ul>
|
||||
|
||||
<h3>
|
||||
<a NAME="Changes to XPCOM happening"></a>Changes to XPCOM happening</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="Changes to XPCOM happening"></a>Changes to XPCOM
|
||||
happening</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -334,7 +464,8 @@ Base ProgID in the interface ID header file</li>
|
|||
</ul>
|
||||
|
||||
<h3>
|
||||
<a NAME="What should I do"></a>What should I do</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="What should I do"></a>What should I do</h3>
|
||||
|
||||
<ul><b><font color="#CC0000">Component Developers</font></b>
|
||||
<ul>
|
||||
|
|
@ -362,7 +493,8 @@ again. The repository may be already doing that.</li>
|
|||
</ul>
|
||||
|
||||
<h3>
|
||||
<a NAME="Issues"></a>Issues</h3>
|
||||
|
||||
<hr WIDTH="100%"><a NAME="Issues"></a>Issues</h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче