| Path: | HACKING (CVS) |
| Last Update: | Sat Aug 18 22:54:10 -0700 2007 |
This is a bit of information for those interested in helping out with the MUES.
We created MUES to provide a generic platform for hosting collaborative environments with a minimum of work on the environment-creator‘s part. We wanted a server that took care of as much of the tedious boring stuff behind the scenes, but without assuming much of anything about what the nature of the environment would be.
To accomplish this, we concentrated on creating a class library that was not only a functional server when put together, but also useful via generalization and/or association. Many of the base classes in MUES double as factories that can load custom classes just as easily as the ones in the distribution, and every class should be inheritable and as decoupled as possible from other classes. If you find something that doesn‘t meet this criteria, it‘s most likely a bug, and we‘d appreciate it if you‘d bring it to our attention.
docs/ - RDoc documentation utilities and libraries experiments/ - Miscellaneous experimental bits of code ext/ - MUES C extensions lib/mues/ - MUES Ruby extensions events/ - Event classes filters/ - Filters for the MUES::IOEventStream listeners/ - Connection listener classes metaclass/ - The MUES Metaclass library os-extensions - MUES::ObjectStore backend and memory-manager classes services/ - MUES::Service classes server/ - Server instance directory tests/ - MUES::Unit unit tests
The server is mostly code complete. Starting and running the server with a rudimentary environment works fairly well. That being said, there‘s still a lot of work left to do.
The Metaclass system works, but is lacking the integration code and utilities necessary to make it truly useful. You, of course, don‘t have to use it, but there‘s no built-in mechanism to allow one to reload Environment classes, so it requires a server restart every time. The mechanism in the CommandShell for loading/reloading commands could be fairly easily adapted to work for that purpose; doing so is one of the things we might do if there‘s a demand for it.
The ObjectStore works really well when running with the BerkeleyDB backend, but none of the other backends are working yet. The Flatfile one doesn‘t work under $SAFE >= 2 because it uses PStore, which opens an IO object for each transaction, and File::open is restricted in that level (either the whole operation or just using tainted data — I haven‘t tracked down which). It needs a rewrite to either use a simple mapped file like the Cold Project‘s Genesis server database (web.cold.org/genesis/home.html), or use a thread that starts on instantiation that runs in $SAFE = 1 to do the actual transactions.
Unit-testing has been written for some classes, but not others. Some current unit tests don‘t test their targets very thoroughly.
Documentation about higher-level stuff (ie., how to write an environment, how to write a command, etc., is woefully inadequate when it exists at all. The API docs are very good, thanks to Dave Thomas’ RDoc tool, but that‘s only useful when you know what direction you‘re headed in.
For specifics, see the TODO file.
Please submit patches in unified diff format with a brief description of what your changes do.
When writing larger bits of code that you would like to contribute, please follow the coding standards posted on the MUES project page:
http://mues.FaerieMUD.org/codingstandards.html
You can check out the MUES CVS tree anonymously by following the instructions posted to: cvs.faeriemud.org/cgi/viewcvs.cgi/
Currently that consists of the following commands:
$ cvs -d ':pserver:anonymous@cvs.FaerieMUD.org:/usr/src/master' login (Empty password0 $ cvs -z4 -d ':pserver:anonymous@cvs.FaerieMUD.org:/usr/src/master' co MUES
Thanks for your interest!
$Id: HACKING,v 1.2 2002/10/31 07:27:49 deveiant Exp $