Ari Heitner wrote:
>
> okay.
>
> so i've hashed through a lot of other stuff with some good advice from brendan,
> jband, and mstoltz.
>
> there does remain one issue:
>
> I still need a way to give XPCOM more type information, at startup.
> alternatively I need a way to support multiple locations for type information.
>
> currently typelibs are loaded by xpti from the components/ directory (or so i'm
> assured by jband). i'm not clear whether there is a database of all type
> information (is that what components/xpti.dat is?) or whether that's stored
> somehow with the component registration, or whether xpti just magically picks
> up any and all xpt files in components/.
>
> In fact, i started reading code today from nsComponentManager::AutoRegister,
> and saw how dll's for components are (re)registered automagically. But i didn't
> see *anything* that did xpti stuff.
>
> In fact, i don't see any code hooks at all into any of the stuff in
> xpcom/typelib/xpt, or where any of that is used. I can't even make sense of
> that code on its own ;)
The only connection between the component manager's autoreg and
that of xpti is the call to AutoRegisterInterfaces at...
http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsComponentManager.cpp#2015
>
> Is there any documentation (or suggested interfaces/headers, or anything) to
> figure out how the typelib magic works?
No docs. Code. Sorry, few comments.
xpti is in xpcom/reflect/xptinfo. It does all the work of driving
the low-level xpt stuff in xpcom/typelib/xpt.
Consumers of type info only need to know about the interfaces and
structures in
http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptinfo/public/
I'll give you the quick rundown on how xpti works...
xpti's job is to manage the loading and lifetime of type
information. It needs to provide easy access to {name, iid,
isScriptableFlag} for *all* available interfaces. It needs to be
able to load more detailed info on any given interface on demand.
It tries to ensure that the type info is coherent and reduce the
likelihood that incorrect or inconsistent type info is given to
consumers. It is engineered to use the minimum memory footprint
while giving reasonable performance. We are not currently doing a
really good job of partitioning our type info into .xpt files to
truly take advantage of xpti's features to minimize our memory
footprint form loaded but unused type information
(http://bugzilla.mozilla.org/show_bug.cgi?id=46707).
The persistent format of the type info is the .xpt files. xpti
also supports .xpt files that are inside .zip and .jar file
(though we currently don't use that feature).
In order to know where to find any given interface info (and to
provide easy access to the {name, iid, isScriptableFlag} data for
all interfaces), xpti builds and maintains a persistent file
(xpti.dat) that acts as an index of the various .xpt files. (This
is a plain text file - you can look at it). On startup xpti.dat
is read in to build an in-memory index. If xpti.dat is not found,
then it is regenerated by scanning the components directory for
.xpt files (and .xpt files in .zip and .jar files) and then
loading those files in a predictable order to discover and (to
some extent) validate their contents. Whether xpti.dat previously
existed or not, at this point xpti will have an in-memory index
of the .xpt files and a corresponding xpti.dat will be on disk
for next time.
If AutoRegisterInterfaces is called then xpti will scan the
components directory and build a list of .xpt, .zip, and .jar
files along with their sizes and timestamps. It then compares
that list with the information in its index. Depending on the
extent and type of difference between the lists it either does
nothing or reads new or changed .xpt files. It also deals with
.xpt files having been deleted. If the in-memory index changes
then xpti writes out a new xpti.dat file.
Loading of the actual type info from .xpt files is done
incrementally. If a consumer asks for any detail of an interface
(other than the data we read from xpti.dat) then the necessary
.xpt file is loaded. This may or may not also load info for
additional interfaces - it depends on what else was in the .xpt
file that needed to be loaded.
xpti internals were not meant to be easy to change. They were
meant to be compact. Arenas are used both to recycle sets of
stuff with common lifetimes and to minimize heap overhead (while
maintaining appropriate alignment for the given types of data).
The type info reading is otherwise very malloc-happy for tons of
tiny blocks.
Loading .xpt files from multiple locations will further
complicate much of this.
>
> What I'm doing remains (theoretically) simple: providing mozilla with new IIDs
> and CIDs (type and implementation information) that is not part of mozilla,
> since it's part of an embedding application. Dynamically (well, at application
> starttime) telling XPCOM about new components at runtime is easy:
> nsComponentManager::RegisterComponentLib (or RegisterFactory, or anything
> related). I also need to dynamically tell XPCOM about new types. Alternatively,
> I need a way to register either just the type information, or both the type and
> the component information, seperately from the mozilla installation (which is
> considered part of the "system").
You can tell xpti about new types by writing .xpt files and
calling AutoRegisterInterfaces. As I pointed out elsewhere, You
can modify xpti to use some other (single) directory location. In
your system you can put the 'system' .xpt files and the 'user'
.xpt files in the same directory, no?
I hope that you are convinced that hiding type info is not an
appropriate access control mechanism.
>
> As I've said before, if someone says, "you can't do this yet, but here's where
> it would go," i'll write it. there is an (old, old) open bug about the
> single-location for component registration information....
rayw was - at one time - developing a scheme to load components
(and presumably .xpt files) from various places. plugins would
'like' to not need to copy .xpt files to the components
directory. I don't know that the need is great or that anyone has
plans to do the work to make this happen.
John.
>
> ari
