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 ;)
Is there any documentation (or suggested interfaces/headers, or anything) to
figure out how the typelib magic works?
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").
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....
ari
