Last question of the day (This one's easy!)

[Martijn Faassen]

Nolan Darilek wrote:
[snip]
> Initially, I thought that if a MUD server could be written in Java
> (http://www.twistedmatrix.com) a Python version would be smaller,
> easily readable, etc.

> Now, however, I'm becoming concerned about how possible/practical this
> would be, and if I'm possibly using Python for something for which it
> isn't intended. I began doing research into Python's speed vs. Java,
[concerns about Python's speed for use in a mud server snipped]

I've done some thinking about the use of Python as a mud server language
as well, and I suspect it's well up to the job. Compare for instance with
Zope (www.zope.org), which implements a dynamic *web* server in Python. If
you can do that, you can do the same for muds. Of course Zope has parts
written in C for speed, but you can do that for a mud server too, if
necessary.

Also compare with lpc of lpmuds, which you mentioned. I doubt lpc code can
run that much more quickly than python code (if at all), and lpmuds have
been around for years now and work just fine.

Python has a lot of exciting technologies that would make building a mud
easier. Lots of standard stuff is already done for you, for one. Then there
are interesting things like the Zope object database which you may want to
use to build a persistent database for a mud. There's all sorts of things to
make Python talk to remote methods as well (CORBA, XML-RPC, etc).

My main concern with using Python as a mud server is infinite loops, and
costly methods in general. A mud shouldn't 'hang' when some coder inside
happens to code a buggy object with an infinite loop in it. Instead the
mud should detect a method is costing way too many ticks (or bytecode
executions) and abort it. I've seen two main ways to get around this; one
is Zope's approach; basically it limits its DTML so that you can't write
infinite loops. I don't much like this one for muds, as you'd like people
to use Python to extend it.

Another possibility is to do something like Will Ware's microthreads do;
they work by using the 'tick' approach and thus even if one thread loops
infinitely the rest is still fine. Unfortunately microthreads depend on
a module that contains a patched Python interpreter loop, which isn't
exactly easy to maintain..

I only have limited knowledge about how full fledged multithreading can
help here, perhaps someone else can give an answer.

I've also been curious how Joe Strout gets around this problem in his POO
(a MOO inspired Python based mud).

Regards,

Martijn

-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?