Ari Heitner wrote:
>
> 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 think this is a very bad assumption. Mozilla libraries are not
intended as system libraries to be used simultaneously by various
applications. They do not generally protect their writable config
files (e.g. xpti.dat and others) from access by more than one
process. There is no promise that interfaces will stay the same
from one release to the next (except for the very few 'frozen'
embedding and plugin interfaces). The mozilla libraries work as a
set for the application they ship with. It is simply dangerous
(and a disservice to the user) to trust that some other
application can dynamically load and use those libraries without
bad things happening.
The right thing to do here is to factor out what you need of the
mozilla code and ship your own versions. There is information
available on building xpcom standalone and xpconnect standalone
(which adds the JS engine and xpconnect).
You can then have whatever control you want over what
functionality is present and where components and typelibs go.
I think you are glossing over the security issues too. If I were
you I'd jettison the entire caps system (xpconnect standalone
factors that out for you). The browser security model is a bad
fit for what you are talking about. It does many things you don't
need and doesn't help much for what you do need. Forget about
"UniversalXPConnect" and "nsISecurityCheckedComponent" - these
are just messy schemes used by the caps system to accomplish its
goals for *browser* security.
Instead, think only about implementing security at the "JS
calling C++ code" boundary. That is exactly what xpconnect lets
you control using the nsIXPCSecurityManager interface. You can do
this easily by writing an implementation that maintains a list of
"accessible" interfaces and vetos any attempt to access an
interface not on the list. This is not rocket science.
Again, I *really* think that trying to piggyback on libraries
owned by the installed browser is a big mistake.
John.
>
> >
> > 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
