[MUD-Dev] Re: PDMud thread summary

[James Wilson]

On Fri, 23 Oct 1998, Chris Gray wrote:
>[ApplePiMan:]
>
> >Agreed. But I'm curious: where do you see unnecessary complexity in the 
> >system as we've discussed it to date?
>
>I'm guessing that a lot of that reaction was coming out of some of the
>stuff Niklaus was saying. I really did think he was meaning sending
>actual data through some kind of pipe, rather than function calls.
>Also, some of the suggestions about having native code and MUD-code
>be plug-and-play interchangeable can get messy.

One big issue is GC - having mud-code translated to C/C++ would allow you
to impose extra constraints on the generated modules so they can abide
by whatever GC scheme you impose on the interpreted machine. (This is
something that bit me in the ass when I was linking up perl with C.) It
would also be good to wrap up those constraints in nice packages so someone
could easily write/tune the module by hand rather than generating it clean
from mud-code.

Then of course you'd have to choose what sort of gc you want. copying?
compacting? mark-and-sweep? generational? train? different people would 
probably want radically different things (for some it may not be an issue).

Has anyone defined the distinction between 'core' and 'plugin' yet? It seems to
be pretty fundamental... there must be some basic feature set which every
module can rely on. At a minimum this would have to include dynamic loading.
Further you would need threading (as you wouldn't want to mix thread-aware
modules with thread-naive modules) and, I would argue, gc (as the choice of
algorithm, write barrier etc affects how everything must be coded). These are
all things on which every module has to agree, and which require some amount
of cooperation from them. Other things such as networking are more ambiguous,
and could well go into a privileged module. Here, networking can be seen as
having a much more limited audience than threading or gc, i.e. not many
modules should probably be doing networking - they should be dealing with
abstract i/o or inter-object communication instead.

James