[MUD-Dev] Re: DevMUD: Inheritable modules

[Jon A. Lambert]

On 30 Oct 98, Adam J. Thornton wrote:
> I very much like the idea of doing the core of the server in ANSI C with
> POSIX functions, and implementing (as a module, of course) an OO scripting
> langage for actual world development on top of it.
>

I think the idea of a something called the core is sort of a cop out 
in designing a system.  Basically it's a blackhole, where one can 
dump anything with out really thinking about interface.

Some may also know this as the blob phenomenon, where a single
amorphous controller class or system management module monopolizes
all the processing.  The surrounding modules become little more than
a means to encapsulate data and ultimately serve the blob.
One solution is to slow down, stop, and refactor the responsibilities
of the disparate functions which have been tossed into the blob.

Then again maybe I'm just scared... It's hard to kill the blob. ;) 

> That's mostly because I understand C a lot better than I do C++; this is
> basically a personal aesthetic judgment on my part.  However, I think the
> core will tend to be smaller, cleaner, and easier to read if we stick with
> C.

I prefer C++ because of aesthetics.  :)  Different strokes.  But I 
see no reason why each component couldn't be written in C or C++.  
There does seem to be some agreement here that each component module 
expose itself in terms of a C call linkage structure. 

> Then we have the problem of what belongs in the core.  My candidates are:
> Networking primitives (however, leave authentication et al at a higher
> level, whether in C or the MUD language) (what I've done in the system I'm
> working on is to have a per-connection value that represents what
> crypto/authentication mechanism that connection uses, so that's really a
> protocol design issue), and the notion of connection and thread-or-process.
> I think there ought to be a one-to-one thread-to-connection mapping (there
> may of course be non-connection oriented threads going on, but each
> connection presumably requires its own thread, unless we want to make the
> I/O model nonblocking, which I think will get unwieldy for large numbers of
> players).  Also message queues of some sort to handle the data that each
> connection is transporting.

Let's just say there are a number of modules that need to be in place 
to get "core" functionality.  Each of them should be designed 
independently of each other but expose an interface.

A network module should be able to handle requests from any module,
not just a centralized monolithic core.  The network module could
be reactive, that is only respond to requests, like polling,  input 
output, closing connection, etc).  A reactive network module demands 
that the module requesting information (assume the core) know all 
about how input, output, poll, sequencing is done.  OTOH a proactive
network module would both send messages and respond to messages
to any interested modules.  The only thing required is that the 
network module know who he will be talking to and who he will
be responding to at runtime.  I think a each module should have it's
maintain it's own configuration data.  

I think all that should be required of the core is that it read a 
configuration, load and startup all the modules.  At that point the 
core is done and goes asleep.

> So basically the core (in my idea of it) would not do much except handle
> connections, broker them, and multiplex/demultiplex the data going through
> them.  This is going to be kernel-like, so it's not really that important
> to be able to dynamically load it or unload it--I can't imagine a MUD that
> did not provide these services.  And I think this bottom layer would be a
> couple thousand lines of C: quite small.
 
I see a network module as an independent component that behaves 
just like a smart realtime device.  A useful way to visual it 
is like a row of local connections all controlled by the network 
module. Now load a another network module called the ipc_network 
module. No we have another network running on the same server sending
and receiving messages from us.  Perhaps this secondary process
is using a core which is configured to run ipc_network only.
Let's load a third network module, called the rpc_network module.
Now we're receiving and sending messages to a network running
on a secondary server.  There's more.  Let's load a network module
called playback.  Playback simply reads and writes dozens 
(nay hundreds) of local files that look suspiciously like user input
and output logs.  We've now got a regression testing mechanism or a 
way to simulate fictional server loads.  Wait I'm not done yet...
Perhaps I don't want to load the network module at all. I load
my console module.  Now I'm the only one who can play and develop.
And before I leave off, how about if I load the the playerbot 
module, in addition to my network driver, which wonders about the
mud asking everyone and if they've seen a mythical place 
called Midguard.   What about network indirection modules, where you 
can play muds within muds within muds.... ok ...enough for now...
I'm thinking totally independent components here.

Any thoughts.... :)
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--