[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

[Jon Leonard]

On Fri, Oct 23, 1998 at 09:32:43AM +0200, Niklas Elmqvist wrote:
[modules and pipes for intermodule communication]

> Maybe one-to-one pipes would be better since it would minimize the traffic
> flow and "water sprinkling". However, it would also force central modules
> such as the parser to become much more complicated since they would have
> to keep track of where different pipes lead and what to send on them. Not
> sure about it myself.

I recommend one-to-one pipes as the underlying primitive (probably with
function calls as the even more underlying primitive), and using a module 
to do broadcasts.  More generally, the pipes module should be the module
that gets sent messages that might need to go multiple places, and it
resends messages to modules that have expressed interest.  It's almost
as efficient for real broadcasts, and substantially more efficient for
things that need to go to a few places.

The other interesting characteristic of one-to-one pipes is that they can
be implemented as sockets in a distributed MUD.  Careful partitioning for
a distributed MUD is very important, though.  Network communication is
a lot slower than local function calls.

> We will also need a defined sequence for modules to disengage themselves
> from the module community and be unloaded. 

This is garbage collection in another form, and the same algorithms
apply.  A module using another module maps to a pointer, and unloading
a module maps to deallocation.  If we need to force a module to be unloaded
for some reason, then we'll need a broadcast protocol for saying
"everybody stop using module X!".  This may avanlache, as other modules
that depend on X try to get those that depend on them to shut down.  This
might be the best way to shut down a MUD, actually.  Just tell everyone
to stop using the bootstrap, and away it goes.

> Or is there a better alternative to a message-based communication system
> like this? Anyone with more experience in these things than I?

For the capabilities stuff, we might be better off if each module had
a list of "requires a, b, c" and "provides x, y, z".  Then the loader (or
compiler) can tell you immediately that the combination of modules you've
selected isn't viable.  This can be extended to include requirements like
"no threads".  It can keep incompatable modules from being mixed by having
them require "no X" and provide "X", which should be interpreted as mutual
exclusion.

A more sophisticated tool would be able to help by listing what combinations
of modules could be used to achieve some feature set, without having to
try them all expirimentally. 

Jon Leonard