[MUD-Dev] An Idea... Mud Development Framework

[Chris Jones]

On Sun, Jan 21, 2001 at 12:53:24PM -0500, Jeremy Lowery wrote:

> About writing another scripting language.. Isn't there already too
> many ways to write a for loop? The reason I think it would be
> worthwild to just hook up an interface to a scripting host is
> because it's pointless to write another language. There are far too
> many as/is. I don't think there would be much, if any, syntax to add
> to a language just because you write it for a MUD. Getting away from
> pure MS technology, I've been looking at the python API, concidering
> imbedding the parser in the mud. Or doing it the other way, extended
> python with C++ modules. The main reason scripting seems so
> appealing to me is because I'm tired of recompiling everything when
> I want to change something. I'm still a bit foggy on what goes where
> though. that is in the C++ and in the script.

The best reason I can think of for writing yet another scripting
language is that it can provide hooks into the design that you can't
get as easily though another language. And it will let you avoid some
of the problems with that other language.

I looked into embedding Javascript, but it doesn't provide any close
ties between "objects" and functions, and really isn't an OOPL.

I looked into Python, which seemed like a clear winner, until I
discovered that all the file operations you need to ruin the MUD are
built into the core language. (A friend wrote the first
denial-of-service program for the design specification as soon as I
put down Python. She pretty much filled a file in /tmp with blanks
until the disk was full.) I wasn't too keen on having to remove or
protect the file I/O functions if I embedded Python: __import__,
execfile, open, raw_input, and reloads are all built-in functions. But
other than that, Python seemed the best choice: commonly known, easy
to extend, easy to disable certain functionality by simply removing
libraries from the path, and very easy to embed.

So in the spirit of the people who reinvented the wheel, I started a
MOO-like language spec with which I am still discovering the joys of
lex, yacc, and abstract syntax trees. I still believe the "one true
way" is an interpreted system that can be changed while the system is
running, but I'm also beginning to think it would just have been
easier to scrub incoming Python code before passing it to the
interpreter. And it would be way to easy to simply code the MUD in
Python in the first place when I could write a language in which to
code the MUD myself.

How do you plan on keeping people from accessing file I/O primitives
in embedded languages like Python or VBScript? What about accessing
code libraries (for sockets, file I/O, or other nefarious things)? Are
you simply going to have to trust the coders? Are you going to make
all code changes happen on restart?

Chris
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev