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

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Thu Oct 22 20:55:01 CEST 1998


[Niklas Elmqvist:]

 >Well, since the PDMud module community (at least the way I view it) is a
 >very volatile one (all modules should be prone to be replaced/unloaded at
 >any time as well as new ones being added), the Parser module would have to
 >initiate this by doing a broadcast message along the lines of "parser
 >here, to whoever it concerns: tell me your supported requests and
 >triggers, over" or something. *Then* the modules respond in turn, telling
 >the parser what kind of methods they support. 
 >
 >The same kind of query sequence would have to be performed for all modules
 >which want the attention of others. "Oi! I'm here and I can handle
 >this:..." 

I'm thinking its a one versus many situation. Whenever a module is loaded,
it should tell the existing modules what it is capable of, and they can
chose to use new stuff or not. So, when the parser module is loaded, it
asks what everyone currently loaded can support, and sets itself up
accordingly. But, when a new module (e.g. magic) is loaded, it is that
module that broadcasts its capabilities to the existing ones, rather
than all of the existing ones broadcasting their stuff to everyone
including the new one.

Perhaps not all modules are created equally. For example, there needs
to be some module that exports a routine to handle user input (quite
possibly multiple routines, multiple modules). It has to get tied
to stuff coming out of the communications module, which contain commands
from users. Perhaps the 'handles' poking out of modules should have
some kind of type attached to them, indicating what they accept and/or
what they produce. It is this "interface language" that will need a
lot of specifying. We also want to avoid getting too complicated with
this thing - we should keep the KISS principle in mind (Keep It Simple,
Stupid!)

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA




More information about the mud-dev-archive mailing list