[MUD-Dev] Re: PDMud thread summary

[ApplePiMan at aol.com]

At 10/23/98 9:02 PM James Wilson (jwilson at rochester.rr.com) altered the 
fabric of reality by uttering:

>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.

Sounds quite reasonable to me.

>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).

Not an issue to me... but probably mostly because I haven't the vaguest 
idea what you're talking about. <g> Could you perhaps point those of us 
ignorant of such matters to a good resource for learning about the 
various gc schemes?

>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.

I think you nailed the core perfectly, as far as what I personally would 
like to see. And, yes, I would make networking a plugin. If it doesn't 
(within reason) *have* to be in the core, give people the option of 
replacing it with their own module. I can guarantee someone, somewhere 
will want to.

-Rick.



---------------------------------------------------------
Rick Buck, President and CEO  <mailto:rlb at big-i.com>
Beyond Infinity Games, Inc.
See you in The Metaverse! <http://www.big-i.com>