I'm still sick, but we did have a nice dinner with Chris and Shona, so that was nice. More rest today, though I have to do some more work in preparation for Deb's start at work in May.

OK, mathieu, I'll confess that I don't understand why you need to have the IDL info in the application. What if multiple applications use the same interfaces (like GNOME::Panel, or whatever)? Why should you tie interface to implementation like that? Multiple copies? What about implementations in Perl or JavaScript or Java or Python, which don't have the same _init hacks? I guess I don't see why you can't keep ``typelibs'' (meaning: files that describe interfaces) separate, which would also seem to reduce the likelihood of having someone ``update'' the interface when they update their implementation (``I'm the only applet in GNOME CVS that uses GNOME::MagicThing::1.0, so I'll just update it in place. What? Someone else has a Perl applet that uses it?'').

My experiences with Mozilla autoregistration also tells me that you probably don't want to grovel over $gnome_prefix/lib/IDL/*.so at every GNOME startup.

In more detail, here's what I propose:

• A typelib compiler (similar to xpidl -m typelib) that generates typelibs from interfaces, and probably a linker like xpt_link. The typelib compiler and linker are run on IDL files to product typelib files, which are stored in $gnome_prefix/share/typelib.
• The IR implementation reads in the typelib files at startup, and constructs whatever internal structures it needs to serve things according to the IR interface, etc. (You'd probably want to do incremental loading, by only loading the file header and interface directory entries (names from Mozilla's implementation) at for each file, and then ``faulting in'' the complete entries as required.
• You'd might want to distribute sets of typelibs independently from implementations, actually: gnome-core, gnome-code-devel and gnome-core-typelibs. People might actually want to use the Power Of CORBA to manipulate GNOME pieces from other machines, or provide alternate implementations of gnome-foobar in another (non-C) language. Or maybe you don't care; I'm not religious about the packaging, and will just install whatever Helix tells me.