|
|
|
Some notes on my current project.
The server is now running and publicly accessible:
-- KevinReid - 11 Jan 2003
The mud is implemented using the Cold driver. I chose it mainly because it offered built-in transparent persistence and more flexibility than the MOO driver, and my previous experience with implementing persistent MUDs with VirtualMachines not designed for the purpose (MoebiusMudEngine, my mpMUD, and a few other things) tells me that there are too many pitfalls in that approach.
It is intended to support free user programming, multiple virtual world implementation approaches, structured text output, flexible command parsing, multiple simultaneous connections per user account, and whatever else looks interesting.
See also general SecurityConcerns.
Tricky problem. I constructed the current security model mainly based on MOO's system, but without the implicit setuid feature and with support for arbitrary delegation of privileges. Some of the choices were made due to ColdCLanguage's limitations.
There are two principal components: ownership and trust delegation.
Every object may have a single other object designated as owner. That object is the only one which can do such things as editing code, changing inheritance, etc.
Unlike MOO, code does not automatically gain the privileges of its owner. Also, there is no concept of method ownership, as yet.
Objects are said to trust their owners. This should be considered a technical term.
If an object has no owner, it can only be edited by members of the system group (see below).
In order to support more complex privilege structures, each object has a list of trust delegates. If object A is a delegate of object B, then object A can edit any object which object B owns (but not B itself).
Two critical privilege concepts are implemented using this mechanism:
- Groups. A group is simply an object whose sole purpose is holding a delegate list, thus allowing the definition of a set of privileged objects so that they can e.g. commonly own another set of objects. Delegates of a group may be referred to as members of the group. It is important to understand that there is nothing special about a group object - any object can function as a group.
- Session authentication. Each session gains privileges to operate as a user by presenting the user's authentication information (currently just a password) to the user object, which adds the session as a delegate of itself.
Security is imposed primarily by methods checking the call stack when they are executed, and throwing an exception if the calling object is not allowed to perform the operation.
All editing operations (defining methods, changing inheritance, etc.) are accessed only by nonoverridable methods defined on the root object, which all impose the policy described in the above two sections.
Methods also have a variety of other options for permissions checks - and they can always define their own.
There is one standard exception to the security system - members (delegates) of the group $system always pass all security checks. This is equivalent to the .wizard property in MOO.
The server currently listens on two ports - one for interactive command-line use and one for HTTP.
The concept of an interactive session with the user has been separated from the TCP/telnet-connection handling, and becomes an object known as a user session. Using Cold's multiple inheritance, the command-line connection object inherits from the session object - but other means of communication (e.g. a graphical client using UDP) might separate the existence of the two.
The command-line connections support the MudClientProtocol.
See TextMarkup for prior art.
All output from the mud is processed internally as XML? - or, more precisely, an internal data structure which is nearly semantically equivalent to XML (see XML Information Set).
Structured text is transferred within the mud until the point at which it must be transformed into a byte stream for external communication. There are currently two ways doing so:
- Raw XML. The internal structure is converted into its equivalent XML text (including proper namespace information).
- Formatted text. The internal structure is converted into human-readable text, optionally with ANSI escapes for styles, in a process much like a terminal-based web browser would use (e.g. lynx).
There is also a (currently very slow) XML parser, which is used in some of the web features (see below).
Each user session has a list of input handlers. Input handlers process lines of text typed by the user.
Input handlers exist to support nested input modes. An example of a nested input mode would be the 'paste' or '@paste' commands that many social muds have - text is captured until an end marker is typed, and then displayed to the other players in the room in a single block.
The default list of input handlers consists of the command handler and the stub handler (which cannot be removed).
When a line of text is received, the first input handler is given the line. It can then process the line and return indicating one of the following operations. It can also specify a remainder of the line to be used for further processing.
- Again: the same input handler should be called again, but using the remainder. This would be used for multiple commands on the same line.
- Pass: the next input handler should be called. Usually when the current handler has recognized some 'escape' sequence.
- Handled: the line has been completely handled.
- Done: the line has been completely handled and the input handler should be removed from the list of handlers.
- Fail: the input handler couldn't understand the line.
There is an integral web server, implementing a subset of HTTP 1.1 sufficient for its current uses.
Things built on the web server:
XML-RPC
Arbitrary methods may be called via XmlRPC requests, though there are some limitations due to data type variation.
Methods and other aspects of objects can be viewed (and eventually will be editable) via web pages.
Very experimental. Objects will be editable via the WebDAV extensions to HTTP - e.g. an object is a "directory" containing "text files" which are its methods.
The intent of this feature is primarily to offer further options to users for editing methods and other text - particularly, if you have the capability to access a WebDAV server as a filesystem (e.g. MacOSX?), you should be able to use your favorite regular text editor instead of one built into the mud client or server.
|
