On Wed, Jan 03, 2001 at 09:59:59PM -0800, John Bandhauer wrote:
> Ari Heitner wrote:
> > Is there any documentation (or suggested interfaces/headers, or anything) t
> > figure out how the typelib magic works?
>
> No docs. Code. Sorry, few comments.
Works for me :)
>
> xpti is in xpcom/reflect/xptinfo. It does all the work of driving
> the low-level xpt stuff in xpcom/typelib/xpt.
aha! this is the comprehensible code i have been looking for.
> I'll give you the quick rundown on how xpti works...
[...snip...]
> 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.
[...snip...]
> Loading .xpt files from multiple locations will further
> complicate much of this.
>
I think it would be pretty straightforward to add a function with similar
functionality to xptiInterfaceInfoManager::AutoRegisterInterfaces. One code
path in that function is to determine the update situation "there are new
files to register, but my old files are still valid". In which case we call
xpitiInterfaceInfoManager::BuildFileList and merge new files with our
current xpti "workingSet" by calling xptiIIM::AddOnlyNewFilesFromFileList.
But BuildFileList just gets a list of xpt files in components/ ... like
this:
nsCOMPtr<nsILocalFile> dir;
rv = GetComponentsDir(getter_AddRefs(dir));
nsCOMPtr<nsISimpleEnumerator> entries;
rv = dir->GetDirectoryEntries(getter_AddRefs(entries));
so i think literally all we'd need to do is write a function
xptiIIM:AddFile, which would accept a new xpt file, and do the same thing
AutoRegisterInterfaces does in the case where there are only new files to
add, except call AddOnlyNewFilesFromFileList with a fileList that contains
the new file we want to add ... I see no reason it shouldn't work :)
Unless someone thinks this is a massively bad idea, i'll go ahead and give a
shot at doing it. This is intended to be used like i'm using
nsComponentManger::RegsiterComponentLib, which is to add new type/component
info at startup time. Not speed critical. Not necessarily valid except
fairly early in the XPCOM lifecycle (if only because you want all
type/component info available before you start doing anything real). You
could probably argue I'm being a bad person by relying so heavily on
inserting new components at runtime in any case :) but oh well. Full support
for separate component and type registries would be nice, but it's doesn't
seem necessary for what we're doing.
> 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?
that's a problem. The deal is like this:
The part of Sash that needs new type information is extension libraries (the
whole reason this is confusing is that there are two tiers of development
here: the extension library writers, who are literally writing new parts of
Sash; and the JS coders themselves, who use Sash and its many extensions to
write JS applications).
We just provide the framework for this. It's surprisingly little code on the
runtime side (obviously there's a whole complicated Sash development
environment, but that's a whole other story), about 15k lines (plus a couple
of extensions that we provide by default). In order to extend Sash, all you
need to do is implement two things (in C++): some little object
ISashExtension, which tells Sash about the extension library; and then
whatever functionality you want to add to Sash. Which is the key: new
functionality for Sash -- new interfaces for Sash -- stuff we on the runtime
team haven't dreamed of yet.
The Sash developer (who writes "weblications" in JS) picks and chooses among
extensions based on the functionality he needs. These extensions will become
dependencies of the weblication.
The end-consumer of weblications will have to install all the extensions
that the weblications he wants depends on. Which in effect means new types
to be loaded into XPCOM by the Sash runtime. Sash will eventually support
both systemwide and per-user installation of extension libraries (right now
we only do per-user; it's very little code in any case, rarely more than a
few hundred k per extension). As far as the Sash runtime is concerned,
mozilla (more specifically libgtkmozembed.so) is just another system library
that must be present -- like libc or libgtk or anything else.
Which is why we can't (in the long run) use the mozilla components
directory, or somehow hijack our own installation of mozilla. The whole
point of the Sash runtime side is to be super-lightweight. An extension
library is just a few hundred k of object code. A weblication is less,
usually a few dozen k, just html/xml (as much of which can be online as the
developer wishes). The initial Sash install will be under a meg.
Even a minimal installation of mozilla fits poorly into that picture... not
that we couldn't do it; just that i'd much rather depend on the
system-provided mozilla.
>
> I hope that you are convinced that hiding type info is not an
> appropriate access control mechanism.
absolutely not :)
the only issue is, the JS should be able to access the XPCOM objects we say
it can -- and nothing else. It sounds like we ought to be able to have those
objects implement nsISecurityCheckedComponent, since all the XPCOM stuff
that the JS will be able to access has its own security model (the Sash
security model). But we could do an nsIXPCSecurityManager if that's
considered cleaner (since mstoltz says nsISecurityCheckedComponent may or
may not hang around).
cheers,
ari "depressingly more email than code" heitner
