On April 29th, 2002, I began to look at integrating the standalone XPCOM with the LambdaMOO server.
XPCOM is a lightweight cross-platform implementation of the concepts behind Microsoft’s COM. It has been implemented in the process of the development of Mozilla. XPCOM is essentially COM, but cross-platform, hence the XP.
The integration inside the MOO server is not necessarily for any specific purpose, but I have a few plans in mind for what this integration will permit:
XPCOM can be used to allow builtin functions to be compiled into shared modules and dropped into the MOO ‘components’. These builtin functions will be registered with the ‘regxpcom’ program, and be accessible from inside the MOO instantly. There are multiple advantages over doing this rather than the traditional way of modifying the MOO server to add builtin functions. The most major advantage is that XPCOM components can be written in languages other than C. It’s useful to program in an object-oriented language like C++ when you’re programming a builtin function that will be used in an object-oriented environment in the first place. Additionally, plug-in DLLs can be isolated in such a way that the crash of a builtin function will not affect the running of the MOO server.
This has been implemented and is currently undergoing testing. The implementation involved the creation of an ‘IBuiltinFunction’ interface. The plug-in DLL exports an IBuiltinFunction derived interface. The MOO server allows access to its data to the XPCOM component via a set of ‘IMOOData’-derived interfaces.
Another possible use for XPCOM inside the MOO is to allow MOO-code to access XPCOM objects. I expect that originally this will be implemented by creating an XPCOM plug-in DLL that exports builtin functions providing xpcom_createinstance(), xpcom_queryinterface(), xpcom_callfunction(), xpcom_get_attribute(), xpcom_set_attribute(), xpcom_releaseinstance(), and xpcom_isvalidinstance().
xpcom_createinstance() will create an instance of a given contract id, if possible, and return a hash string that represents that instance. Eg:
The string representing that interface is a concationation of the CID, and a pointer address to it to make it unique for each instance. A hash table of these strings will be stored in the server so that implementation of the other xpcom_*() functions is relatively efficient.
Implementation of this idea is pending further thought.
My efforts of XPCOM integration have yield a MOO which can successfully use XPCOM component builtin functions. My work has been based upon the MOO Canada server source, which is a rather hacked up LambdaMOO 1.8.1. The source has some unfortunate usability problems. It is basically customised just for my building and use of it. It should be possible to adapt it to build on your machine. The Makefile-xpcom-lao file is my Makefile. The automake and autoconf sources are not up to date. With some modifications to the Makefile, it should be possible to get it to build for you. Currently, I don’t have any example modules that are fit for publication.
The XPCOM enabled MOO server source can also be accessed by Subversion clients, or browsed with a web browser, at http://stompstompstomp.com/svn/moo/mc/xpcom-enabled-branch.