Obviously, there's a historical component - We use MOO because that's what was used.

Aside from the existing code base, MOO provides some services that would be, at the least, time consuming to re-implement.

more details welcome

-- CoKe - 30 Aug 2004

What services specifically are those?

-- ChrisParker - 31 Aug 2004

Why Use Moo?

To understand why MOO was selected from all of the possible approaches to writing a CONNECT-style CMC, you have to step back into the time. I was working extensively on repairing and stablizing Clover. The server, rhysomme, was quite probably Heechee's (Stephen Underwood) first large scale network server. The client CLover was my first C program beyond 'Hello World.' We both had lots of help from peers (Prisoner, Tale, etc) and NetGods^? (Sandro, Maker, etc), but in the end it was largely the work of our hands. Looking back on it now, but with 15 years of programming and 10 years as a professional developer, I can say for certain: it sucked. Both parts of the application suffered from significant design flaws, failed implementations and the paving stones of Hell (good intentions). It was the hat trick of bad software: inexperienced developers, fluid design and aggressive schedule.

Just before I started work on lily there were several key events which lead to the selection of MOO. First, I was running both CLover and rhysomme under Purify and finding leaks and overruns and stack smashing galore. One of the early runs which tested the famous nyU;! command generated 100K of error reports for the server alone. These reports eventually demonstrated some serious internal architectural defects in rhysomme which were corrupting the user information table at runtime. It was clear that writing these applications in C was great: if you were a great programmer, if you had a lot of time on your hands, or if you had a lot of people to help. As usual, the community was primarily defined by its needs rather than its contributions. There was rarely more than a handful of people and we all were growing up and getting real jobs rather than enjoying the life of a college student. A simpler solution had to be found and Clover was apparently beyond repair. How nice it would be to program in a protected meta-language, something easy to learn so other people could contribute...

Second, once the changes were in place deploying the server was a veritable nightmare of both technology and politics. The machine rhysomme was hosted on was ACM controlled so I had to pass through another person to deploy the new versions of the server, as I was long gone from the RPI community at this point. The state information stored by the server was in a mix of formats and quite easily corrupted. Then there was the issue of upgrading the client, which was always a pain because it generally depended on people to fetch the latest version. How nice it would be to be able to have instant access to both the code and database...

Third...Well, first a piece of background. There are few developers on this earth I respect as much as Deven. Were it not for our too similar personalities, historical connections through Sandro, and often combative exchanges, we might be two peas in a pod. As it is, he is the difficult genius and I am the difficult understudy. Back to the show...

Third, I was up to the top of my waders with work and debugging that horrific mess we call rhysomme/CLover (mea culpa, mea culpa, mea maxima culpa) and it was looking bad. I heard through the grapevine that Deven had a replacement for Clover already underway called conf. I hoped it was good enough to drop Clover and move people over to it. I was still having fun and wanted a role to play in the project. The project was still young and so, understandably, he did not want any help, nor was he ready to publish the code. That he chose a client-less approach really resonated with me, since I was dealing with a codependent client-server application with a binary protocol. With the conf avenue blocked off and Clover collapsing more every day, I started to search for an alternative. How nice it would be to have a minimalist client and a text protocol...

Finally, Maker had suggested MOO to me months earlier when I was tinkering with ideas for a replacement project. As usual, Maker was a few steps ahead of me and it took a month or two before I figured out what he was saying. I read the MOO documentation Friday and grabbed a bootstrapping database from Maker. By Saturday morning I a working version of neo-Clover: /HERE, /AWAY, /WHO, /BLURB and a few other commands. It was obvious, even to my dense skull, that this was an effective rapid prototyping system for CMCs. Armed with MOO I could imagine replacing Clover in a few weeks rather than months or years. How nice it would be to get a system up and running quickly...

You get the idea. The offerings of MOO are:

• It does all of the engine-level work, allowing the CMC author to focus on the interesting parts rather than the network infrastructure. Sure, infrastructure is neat, but how many times does the same code have to be written?
• It has a simple internal programming language which is super easy to learn. Other folks should be able to contribute. Nautilus used to contribute patches and new features often, so it is possible. I made huge revisions without access to the master RPI core.
• It provides instant access to both the code and database. This eliminates the startup-shutdown upgrade cycle, which is the riskiest part of maintaining a networked system. It also allows you to tinker with a command and see the results immediately. For the safety minded, this is a low risk situation. Finally, being able to change the database with a command makes so many changes just incredibly easy. Imagine how that would work with serialized config files on a remote server.
• It was a text-based system with low support for non-printables. Gone were the security issues of VT100 control codes rewriting the screen or faking events. With everyone on regular clients now, this is a non-issue, but ten years ago, this was a huge deal.
• It allows new ideas to be turned into code with the blink of an eye. Even now there were features Prisoner suggested for rowboat which I was able to implement in MOO before he could get started. There is simply no comparison between standard languages (Java, C, C++) and MOO for writing CMC code.

The flaws of MOO:

• The network engine really needs an update. The buffering code should be lossless based on a buffer pool or some well established technique. The "network buffer overflow" error should have been dealt with long ago.
• Access to the source for each verb is not in a revision control system. I do hear and sympathise with people on this, but honestly, it is just an excuse. If you really want to contribute nothing will stop you. If you want a reason to dodge contributing, then this is a good excuse. Sue me.
• There is some support now for 8bit text, but lily does not know what to do with it. This is an area of clear improvement.
• The data structures offered by MOO are extremely primitive. It could do with the addition of first-class tables and sets.
• The destruction of comments is virtually a sin. There is no reason comments could not be stored and then dropped from the compiled version. Using strings to store comments is a horror.
• The implicit documentation assocated with parametric functions is key. We have to note arguement types and values in the header in order to expose this information. It should be visible when the verb is listed as a byproduct of the language.

I am sure there are more...

-- ChristianRatliff - 31 Aug 2004
to top