David Brittain wrote:
>
> What do you mean by the last one in, is that the last 'xpt' file that is
> read? Do all the xpt files get read at every start up, or are they read
> once when first installed and then never again?
Simon was incorrect.
The typelib loader (xpti) Will incrementally learn about type
information. When autoregistration is triggered it looks for
changed and new .xpt files (and .zip files containing .xpt files
too for that matter) in the components directory). The results of
its search are cached in xpti.dat for later use in loading type
information.
There is a specific ordering...
- Previoulsy found interace info always wins; including info
already in xpti.dat.
- Older .xpti files are searched first.
- When the file age is the same the larger files is searched
first.
The idea is that the existing system is assumed to have a stable
and consistent set of interface infos and any new ones are
suspect - they might conflict in one way or another.
As to the actualy loading... The contents on xpti.dat is read at
startup. It tells xpti where to find info it may need. If autoreg
is requested (rarely exccept on debug builds or during
installation) then the files in the components directory are
scanned for new, changed, or deleted .xpt files and the xpti.dat
file is updated if there are changes.
The actual info is not loaded until it is requeested. But, the
.xpt file is the unit of granularity for a load. So, it x.xpt
continas 3 interface infos and we need one of them then we load
all three. With some additional packaging effort we could reduce
footprint somewhat by better partitioning the xpt files at build
time.
http://bugzilla.mozilla.org/show_bug.cgi?id=46707
You can see some of this by setting the environment variables:
set MOZILLA_XPTI_STATS=c:\temp\somefile
set MOZILLA_XPTI_REGLOG=c:\temp\someotherfile
Especially in a debug build where autoreg is done everytime the
REGLOG will show show what was discovered in autoreg (try
touching a file and running). The STATS file will show which xpt
files and interface infos where actually used for the most recent
run of the application.
>
> Either way this doesn't seem like a very robust solution, there _are_
> going to be name clashes and it will break code.
Well, when it comes down to it, there is one and only one unique
primary key here - the uuid. Human readable names are imperfect.
The namespace scheme might have helped save us. But we didnt go
there. The saving bit is that within one C++ compilation set
interface names (which coorespond to C++ class names) had better
be unique or the compiler will complain.
You are perfectly free to use a nice long name for your
interface...
com_mycompany_mydept_myunclesname_somethingoranother.
In your JS code you can alias it all you want...
var MyI =
Components.interfaces.com_mycompany_mydept_myunclesname_somethingoranother;
John.
>
> Dave
>
> > -----Original Message-----
> > From: Simon P. Lucy [mailto:[EMAIL PROTECTED]]
> > Sent: 21 December 2000 16:25
> > To: David Brittain; [EMAIL PROTECTED]
> > Subject: Re: Interface name resolution
> >
> >
> > At 15:56 21/12/2000 +0000, David Brittain wrote:
> > >How does interface name resolution work from javascript
> > work. For example
> > >what happens in the following javascript, if 'plugin' is a
> > reference to a
> > >plugin in the page:
> > >
> > >var plugin = 'plugin id';
> > >
> > >var interface = plugin.QueryInterface(Components.interfaces.IPlugin);
> > >
> > >In this case how does javascript know which IPlugin to use,
> > given that
> > >there may be a number of interfaces called IPlugin. As I
> > understand it the
> > >namespace feature in XPCOM is not implemented, therefore is
> > there not a
> > >problem with multiple vendors providing components which
> > have the same
> > >interface names. Is there any way to get around this?
> >
> > Last one in gets it
> >
> > Simon
> >
> >
> >
> > >Dave
> > >
> > >
> >
> >
