Ari Heitner wrote:
>
> John,
>
> All the functionality to do this (see my previous post, "runtime/startup
> loading of typelibs") seems to be present in both
> xptiInterfaceInfoManager::LoadFile and/or
> xptiInterfaceInfoManger::AddOnlyNewFileFromFileList. Exporting either of those
> (into nsIInterfaceeInfoManager) would make it possible to do what i need, it
> seems.
I've lost track of *precisely* what you want to do here. If you
just want to force xpti to notice a file IN THE COMPONENTS
DIRECTORY without having it scan all the file then you can do
something like what you suggest. If you want to have it also
notice files not in the components directory (or wherever you've
told it to find all xpt files) then deeper surgery is required.
>
> That would require moving some information in xptiprivate.h to publicly
> available headers (since both of those functions take internal
> objects). Alternatively, a new function nsIIIM::RegisterTypelib (or
> whatever) could take only an nsIFile and turn around and call one of those two
> in the implementation.
You are for sure not going to directly expose either of those
function or other internal types. If this functionality is to be
exposed, then a new public method to wrap the call would be
added.
>
> I have to admit I don't understand the semantic difference between LoadFile and
> AddOnlyNewFileFromList; LoadFile seems like a special case of the latter, but
> AddOnlyNewFileFromList doesn't call LoadFile (xptiInterfaceInfo *does* and
> appears to be the only user of that function, but i haven't looked at that code
> closely). I have to admit i find all of xptiIIM a bit bizarre (just seems like
> it's implementing the same thing over a couple of times; this probably means i
> don't understand the differences between the implementations).
These two methods are quite different...
AddOnlyNewFileFromList is meant to only be used as part of
autoreg - i.e. *very* rarely. It is only used when xpti has
determined that some new files are present. It is given an
ordered list of files and each file is in turn loaded into a
sandbox and scanned for interfaces that xpti has not yet seen.
There is validation of the interfaces. The iid, name, location,
and scriptable flag is gleaned from each interface that passes
muster. Then the sandbox is cleared.
LoadFile is used to actually load the xpt file for use during the
normal course of running the application. It *only* pulls in
interface info from the file that we have previously decided
(during autoreg) that we'd like to get from this file.
Neither of these methods by themselves will get you what you seem
to want. AddOnlyNewFileFromList is called in the context of a set
of new files that xpti has decided to 'accept' You have to look
at the other things that happen when it is called. Especially
xptiManifest::Write and MergeWorkingSets. Scanning the files for
interfaces is one thing. Merging the metainfo about those
interfaces with the set of known (and trusted) interfaces is the
key to having that information seen later. Skipping that step
gets you nothing.
No path info about the files is stored in the system. It will
simply not work to tell it to load a file from some other place
in AddOnlyNewFileFromList and then have it later find the file
when it *really* needs an interface from that file. Like I said
before, this is a bigger and deeper change to the code. I'm still
unconvinced that this is needed. I *still* think that embeddings
(yours included) can get away with having one place where they
store type files.
The way I see it, the only transition this code ought to make to
support multiple file locations would have to use an ordered
search path to repeatably be able to build the manifest at
autoreg time. It would have to store a stringified (platform
specific) set of file paths in xpti.dat. Each file would contain
a reference to its filepath (see how xpti manages xpt files
within zipfiles - it is the same sort of factored out additional
layer).
In xpti.dat it would look something like:
[Paths,3]
0,/foo/bar
1,/foo/baz
2,/some/other/place
[Files,3]
0,1,msgbase.xpt,21735,978736112030
1,2,msgimap.xpt,11938,978736418060
2,2,necko.xpt,10161,978730620321
The order in the 'Paths' list will persist the search path. Each
entry in the 'Files' list has a number to say which of the paths
it can be found in. There would be a corresponding abstraction in
the in-memory representation.
A coherent change that fully implements this for xpti could get
into the tree. But, I would have problem with the idea of
accepting a patch to this system to support xpt files in multiple
directories if it did not follow through on the underlying scheme
of xpti.
John.
>
> Anyhow. I was kinda hoping this would make it into 0.7. Obviously that's not
> happening :) but i need to get this moving before i can proceed with any of my
> own stuff.
>
> cheers,
>
> ari
