November 2002 archive


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.

    structure diagram of xpcom interfaces in the moo

  • 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:

    => "##XPCOM#bbf8cab0-d43a-11d3-8cc2-00609792278c#59e7e77a##"

    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.

  • The MOOzilla MOO client is written in JavaScript using Mozilla, and utilizes XPCOM heavily. It should be possible to create a plug-in architecture for MOOzilla, using some kind of common interfaces that the MOO server is aware of. Using an implementation of SOAP, (implemented as an XPCOM module, of course), it should be possible for the MOO server to ‘script’ MOOzilla, or vice-versa, using out-of-band binary SOAP communication streams. Woo! The purpose? … Well, why not create an XPCOM module that wraps Gtk+, and then an interface for it on the client side and an interface for message handling on the server side could allow a Gtk+ application to be MOO-server-driven. Of course, this doesn’t apply just to Gtk+, it could be used for any toolkit… theoretically.

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

XML, XPath, Weblog

Reworked weblog-growlmurrdurr to use XPath for finding XML nodes inside the entry data files. It reduced the uglyness of much of the comment related code. Also moved the source into the subversion repository.

Will probably do the same kind of modifications to the picture system later today. I’ve been alternating between playing with XML and working on the MOOzilla documentation. The two projects have collided in such a way that the MOOzilla documentation is all being written in docbook format now, and I’m developing tools of my own to translate it into HTML. It’s being fun. It’s probably slowing down writing the documentation, but I’m not exactly on a fixed schedule.

Unicode, MOO, and MOOzilla

Spent the morning talking with Jason of Achieve MOO. He came over while I was at Catsy’s in Toronto. The original goal was to discuss things related to the Unicode based MOO, and we did that, as well as touching on other topics of mutual interest.

I’ll be publishing a new unicode patch shortly which allows non-us-ascii keywords and variable names in the MOO. This means that non-english words and characters can be used as variable, verb, property, and function names in MOO code without any unnecessary escaping. Collaborating with Jason showed that there are apparently duplicates of characters in the unicode codepage, such as the semicolon, period, quotation marks, and so on, which must be recognized by the MOO in the future as having the same functionality as the us-ascii versions of these characters. This should be interesting, and I’ll look into it soon for another unicode patch.

Once that was out of the way, it became apparent that the server handles Unicode great, the only problems left were in front end programs. Jason’s native OSX MUD client was able to send text to the MOO, but could not receive it and display it properly. The ‘telnet’ command in an OSX terminal was able to receive but not send, exactly the opposite. MOOzilla was able to do both. We didn’t have the resources available to easily test whether Mooca, the Achieve Java telnet client, could do it correctly and nicely.

Jason was interested in MOOzilla as a client itself. A number of ideas and problems came out of that discussion.

The idea of somehow making seperable windows out of MOOzilla which are MOO driven came up. This has been thought of before, but the way it was discussed here was as windows that could be separated, or could be left integrated in MOOzilla. This would allow a ‘power-user’ to keep everything in one complex window, while a beginning user would have a simpler interface that they could complicate if they chose to. I need to give some thought as to how this might be implemented… but I know that MOOzilla/Mozilla have the capabilities to do it.

A problem that arose is MOOzilla distribution and access. A Java client is easy to access because it requires no software installation, is just right there, and is cross-platform. MOOzilla does require software installation, two pieces of software actually, and the software varies from platform to platform. This would be streamlined a bit by the proposed ‘MOOzilla Package’ which was just MOOzilla, without Mozilla cruft, but would still not be usable in Jason’s teaching environment. So… what would? Hm… if only IE supported XUL/XPCOM. Now, if someone could make a plugin for IE that would allow the running of an XUL application… it would probably be a huge plugin. Could one be made that was MOOzilla-specific? … who knows how to make an IE plugin? Need some magic glue components here…

Linux vs. OSX

Well, I’ve been off-the-air for most of the past couple days while installing a new Linux distribution on my laptop.

I decided to nuke my OS9 partition, because I didn’t care to ever run any OS9 software, and then I had a spare partition. What to do with it? Well, install Gentoo! Built the system all the way from a stage 1 tarball optimized heavily for a G4 system, with altivec optimizations. Whee.

Gentoo is very nifty, and very much fun. It’s not exactly meant for the average Linux user, but it amused me greatly. It took so long to get Linux operational due to requiring quite a few small re-configurations to get everything to build properly. Always remember, when you are root, the lightest touch commands obedience. A heavy hand just gets your system more upset.

And on that note, I was up late last night rebuilding Digital Routes’ qmail services to work properly. Got almost finished and suddenly I was unable to contact DR and the MOO. Waited a couple hours, hacked Mozilla PPC binaries into working by building a small compatibility libstdc++ shard library, and then got a couple hours of sleep. Woke up in the morning to finish the job a few hours later.

I’ve gotta say, it’s really tough for me to decide between using Linux and OSX on my laptop as a primary OS. OSX has a few things going for it, namely the ‘it just works’ factor. Also, some of the commercial software is useful, like Office v.X … but then again, in Linux, there is OpenOffice. Hm… in OS X there is EV Nova. That’s tough to beat.

And on the other side of the field is Linux, which runs way faster. Why faster? No, it’s not because it’s G4 optimized, although that may help a bit. It’s because it is just BlackBox and X, no funkyrific Quartz and Display PDF. This means that it is not as pretty, and it has way uglier fonts, but it is faster. And Gentoo’s ’emerge’ to let me build software like apt-get lets you install software is very fun… but, OSX has fink. Maybe, if fink worked in Jaguar properly, this would help OSX’s side. 😉

OSX has power management which -just-works-. Linux has a lot more configuration. Linux is Open Source, though. So when I can’t hack to do something, I’ll be wishing I was running Linux. On the other hand, when I can’t get a second display to auto-detect, I’ll be wishing I was running OSX. The compromise is to keep both, but it’s frustrating to not be able to access both at the same time. Oooh… that reminds me… OSX can run under Linux with Mac-on-Linux. Maybe I should give that a try.


After playing around with Subversion yesterday for a while, I’ve jumped head long into it today. I upgraded to run an Apache 2 server to run a Subversion server, and then moved a pile of sources into it.

I split apart all the branches of the MC-server CVS project into branches in the subversion source after merging them with the head revision, too.

The repository is at and has some nifty code in it, in my opinion.

Also, tackled some MOOzilla issues today. Some of them I didn’t know about, but I wish someone had told me about them…. tsk tsk.

1 2 3