History

Initially, this project started as a port of LambdaMOO to Java. Of course, I didn't even get halfway through the first design without realizing a million things that were either a.) annoying design choices in lambdamoo, or b.) practically impossible to implement in java. i got pretty far, too, before i realized this (in fact, i still have the original version of innerspace written in java using mucho rmi ). i realized that there were a number of things that i wanted to implement that other mud/moo/m* packages just didn't. btw, i'm going to use the phrase mud from here on, even though it's an over-simplification.

But before I get to anything else

i would like to thank the twisted python project, specifically matt "glyph" lefkowitz, for the marvelous framework they created, which let me skip large amounts of uninteresting coding to focus on stuff i liked. there was a huge jump in stability and functionality when i switched from a horribly hacked version of PyRO (also a fine framework, at least, before i started screwing with it), to an only slightly hacked version of twisted.

additionally, i have to admit that i borrowed a number of ideas and design methods from the things i learned while working with glyph on a sort of predecessor to twisted-python -- a java-based text-based game called divunal, run on an engine he created called twisted reality.

just as a story for posterity, because i don't know if it's out there anywhere, twisted-python started as a port of twisted reality to python, from java. when glyph mentioned his work on this, i hadn't learned python yet, and i believe my words were, "who uses python? why don't you just write it in perl?"

moving on.... ;-)

things muds should have

• authoring support/permissions model - i wanted to be able to safely give any user programmer's rights, without having to worry about the havoc they could bring on the system.

(this partcular goal fell a bit short with the destruction of python's RExec framework. currently, it IS NOT SAFE to provide programmer rights to untrusted coders. however, the framework is there to provide a restricted execution environment, and work is underway myself to provide a reasonably secure environment.)

• an elegant internal programming language - initially, i was going to just embed a python interpreter into my java code, but i realized that python's cool factor was just too great. so now the whole server is written in python.

• better object referencing - many muds suffer from issues with naming objects. there's basically two established methods; you either assign each object an arbitrary unique id (lambdamoo's method), or ensure that no two objects share the same name. these methods had various shortcomings.

my solution is nicer, i think. the inner.space.registry keeps track of all objects by name and id. so for the most part, you just refer to objects by their name. but if there's more than one item with that name, an ambiguouserror is raised by the parser, which asks "when you say, 'candle', do you mean candle (#456), candle (#726), or candle (#5)?"

• a graphical object editor - so i may have come to appreciate unix, but i still love my macintosh. by the same token, i want to be able to see at a glance all the major attributes of an object and be able to edit them easily.