On Tue, 2 Jan 2001, John Bandhauer wrote:
> Ari Heitner wrote:
>
> > and my problem is still the same: i need XPCOM to see typelib's even if they're
> > not in components/, since i don't have access to that directory. I'd be happy
>
> xpcom is built of multiple subsystems. You are pointing out a
> method of the component manager. The part of interest here is the
> Type Info Loader (xpti). The current mozilla-the-browser really
> only needed to load xpt files from one place. So that is what the
> current code does. It was not completely clear to me whether or
> not you are doing your own embedding of xpcom (where you can
> build your own version of the binaries) or you are instead
> building a system that relies on users having binaries from other
> vendors. If you have control of the binaries and having xpt files
> come from only one directory (but not the current place) is OK
> with you then you can reimplement:
>
> xptiInterfaceInfoManager::GetComponentsDir
> and
> xptiInterfaceInfoManager::GetManifestDir
> at
>
>http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp#162
>
> GetComponentsDir is the place where xpti will find and load xpt
> files.
> GetManifestDir is the place where xpti will read and write
> xpti.dat.
>
> Both of these methods need to build and return a new object
> implementing nsILocalFile each time they are called.
>
> If you reimplement these methods to point elsewhere and copy all
> the existing xpt files to that new place then it should just
> work.
>
> An alternative to the above is to leave that code alone and
> instead change your copy of the implementation of
> "GetDirectoryFromDirService(NS_XPCOM_COMPONENT_DIR, aDir);". I
> *think* that would change where xpti finds xpt files *and* where
> the native component loader find .dll files too. I'm not sure if
> you want that or not.
>
> If you really need to have the xpti system find xpt files in
> various places then there is a much larger problem. This would
> require larger structural changes to xpti. This would require the
> concept of a search path, a more complicated file search scheme,
> and another level in the internal hierarchy to describe the
> directory in which a given xpt file was found. I'm in no rush to
> do that if it is not *really* needed.
>
I'm not sure that's really what I need.
On further reflection, late registration of XPCOM components is key to Sash
(from the Sash webliction's point of view). That is, once you're running
untrusted JS (which is what Sash is all about; it's just that JS now has some
useful system libraries. if you're not careful, evil can easily ensue :), only
the components specifically permitted to this weblication should be
available. Currently, this is acheived by inserting XPCOM objects (representing
libraries authorized to the weblication) into the ComponentManager at
runtime. This seems to suggest that all we really need is runtime insertion of
typelibs, the same way we can register new XPCOM objects.
Now really we could use the full ideal system supporting multiple
registries. Sash would just have its own registry, containing all installed
extension libraries. We'd only make the appropriate ones available through
XPConnect during weblication startup. If this is what's preferred, I'd be
willing to make xpti do the necessary magic. Blizzard pointed out the bug
(http://bugzilla.mozilla.org/show_bug.cgi?id=14923) about this....wow, that's
old :)
But I'm not 100% convinced that's what I need. If I could just say to the
ComponentManger "here's another typelib for you" at runtime (or even have it
look for typelibs at the same time/place i register component shared
libraries) that would be fine. This would save the pain of coming up with
policies on multiple typelibs. Of course it presupposes that loading a typelib
dynamically is easy ...
Well. Either way, this *is* how i want to do things, since it makes Sash
*extremely* clean (Sash becomes just a formalization for "writing applications
in JS, using nice libraries exposed through XPConnect" which would make
the Free version even cleaner than the 'doze version which would make me
mega happy). So I'm putting myself at ... well... whoever's disposal.
cheers,
ari
