[MUD-Dev] Scripting Design Notes

[Mike L Kesl]

. o O ( Scripting Language ) O o .
(mlkesl 980716 - revised)
(mlkesl 980711 - created)

Problem: Objects should be as realistic as possible.
Goals: Allow contributors to define an objects realism fully and easily.

. ( How ) .
The obvious solution is a scripting language. I do not think there is
any paradigm that we need to break here in deciding the means to reach
the goal. A scripting language is about as good as it gets, aside from
the actual hard code.

. ( What ) .
I am considering using jPython <http://www.python.org>. The other
consideration is to allow contributors to use java in a secure way
using a hard coded api of appropriate scripting functions. I think
something that is purely interpreted would be nice, but I am not sure
if that is theoretically possible in a purely platform independent
project, unless of course if the interpreter is written in java, which
could mean a class library in the case of jPython, I am not sure.
Otherwise we would have to write our own interpreter for the java
method. This method would really only try to compile the script, making
the java runtime environment do most of the work. More investigation of
Java Python is necessary, and perhaps other languages.

. ( Design ) .

Should we make the system fully functional and hope for smart
contributors, or should we assume the worst from contributors and not
allow certain things.

The most obvious security threat is that a scripter could call
functions in the code he or she should not be. This problem is
eliminated by the very definition of a scripting language. Avoiding
this problem is usually the main part of the scripting language tied
closely together in a brawl with flexible functionality.
	
Depending on the implementation, there could be a security threat in
the form of excessive memory usage. For example, a contributor might
decide his mob needs to memorize the description of every object on the
mud. Obviously memory and time consuming, but maybe not quite to
obvious to some likely contributors. An elegant solution to this
currently eludes me. It would mean limiting the allocation of
variables, some or all. The limiting could be done by quantity, or
type, or memory usage, or a combination of the three I am thinking. The
last option sounds intriguing and may be well implemented in other
places in the system warranting that work be put into it. (Such as the
thread rules or object reuse rules)

Another question to consider, if whether or not we will allow
inheritance. Again this may directly affect our choice of
implementation or vice versa. Should it allow them to extend item types
into their own subclassed item type. Thus making a "katana" type from
sword? or not...This would be good with smart contributors, but
probably not a good idea given the quality of most people who will be
contributing. I am thinking no...

(-[= open ended file =]-)