[MUD-Dev] Re: PDMud thread summary
ApplePiMan at aol.com
ApplePiMan at aol.com
Sat Oct 24 19:25:42 New Zealand Daylight Time 1998
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
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
>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 Buck, President and CEO <mailto:rlb at big-i.com>
Beyond Infinity Games, Inc.
See you in The Metaverse! <http://www.big-i.com>
More information about the MUD-Dev