[MUD-Dev] Re: DevMUD - thoughts.1

[Niklas Elmqvist]

On Sat, 24 Oct 1998, Chris Gray wrote:

> Well, instead of working on my own MUD, I've decided to put down some
> thoughts about DevMUD. I find that I think best about something when I
> can understand how its going to work, in terms of possible code. So,
> some of the stuff here will be at a lower level than you might expect
> for this stage of design. Don't worry about it, that's just me thinking
> out loud!

My own MUD is suffering, too, but I really think that this is a better
cause. Plus I've already learned too much stuff on these past few days to
even be able to go back to it now! Complete redesign, if it ever happens,
though it seems more likely I will implement it using DevMUD as its base.

Then again, I might see if I could whip it into a sort-of-working state
and use it as a prototype for showing off my own thoughts. It would
probably be good to have a simple prototype of any architecture we wish to
use so that we don't go out on a limb with something we are not sure will
prove to be the right way for us.

>     Alternatively, we could drop the requirement that modules be allowed
>     to be native or MUD-language, interchangeably? That would at least
>     allow native modules to communicate by direct function calls, which
>     is the most efficient.

I would like to add my vote to dropping this requirement. There should be
a clear distinction between native code modules which are used for
low-level stuff and MUD-language code used for manipulating the world. I
guess this is one vital point where we would differ from mainly-soft-coded
servers like LP and Cold.

> - there was some talk about matching up the interfaces of the modules
>     based on function type and parameters. I think instead we need to
>     define a set (which can grow as needed) of interface kinds, which
>     give a purpose to a given exported definition or reference. Those
>     kinds implicitly include the required function prototype. This
>     will hopefully be clearer in some examples.

Hmm. Having fixed function interfaces seems a little restrictive to me,
but may be the only way to go if we are not to use some other type of
message mechanism (allow me to briefly reiterate that a bus-based
mechanism is in reality an O-O abstraction of function calls/pointers with
the benefit of supporting distributed calls for RPC and CORBA-type
proxies). But what happens when you add need to add more function
interfaces? You would have to update and recompile all affected modules
(hopefully the core exec would be able to stay out of it).

> - threads. My current server isn't threaded, but that doesn't stop me
>     from believing that DevMUD should be threaded. I believe I saw a
>     suggestion that each module should have a thread. That doesn't
>     work too well if the inter-module interface is a function call. That
>     only works if all data going into a module is copied into a record
>     and queued, ready to be processed by the thread of that module.
>     That is imposing unneeded inefficiency. Some modules (e.g. a
>     socket module) will need internal queues (when sockets fill up),
>     but it would be better to not impose that on all modules from the
>     outside.

I agree that it may become inefficient. Once again, I will state that
queueing of messages like this can easily be hidden in the bus system. 
IOW, the modules won't have to deal with it. And although I do not use
multi-threading in my own project (because I lack experience in the
field), I think it should be a requisite of DevMUD.

(Sorry about losing the layout of the original post here, but I screwed it
up by accidentally hitting Ctrl-J (justify) in Pine...)

[Parsing:] 
> Each grammar contains a table of words and their synonyms.  Words which
> are verbs describe what the structure of a command starting with that
> word looks like (so, this doesn't extend to other languages than English
> very well). This description is just a selection of one of: 
> 
> - no other words in the command 
> - a possible extra specific word, then a noun phrase 
> - a noun phrase, a specific word, a second noun phrase 
> - uninterpreted - pass the word list on 
>
> It's a bit more complicated than that, but I hope you get the idea. A
> very simple structure, but it handles most input reasonably well. The
> key is, that associated with each verb word is a reference to a
> MUD-language function to call to process the commands that match that
> verb specification. (The same word can be the verb word for more than
> one specification - the specific extra words are used to choose among
> them.)  So, initially, the parser module exports an input handler
> routine, and a routine by which other modules can tell it about verb
> forms and what to do with them. As modules are loaded which handle
> various verbs, they call that second routine in the parser, which then
> builds up internal structures about the new verb forms. When a module
> is about to be unloaded, it would have to tell the parser to remove
> its entries for the verbs forms that are going away.

I *really* like this parser. Hopefully, we'll be able to do something like
it 

> Because all of this is so different from what I've currently got, I have
> trouble convincing myself that it won't be too restrictive. I need
> convincing! 

I've been arguing with myself about this too, but the difference is that
my current project has a similar (if not as similar as I'd like it to be
:) structure to DevMUD so I have had more time to convince myself. I now
believe that a system like this requires some careful designing in the
initial stages, but later on would allow for some amazing possibilities.
That said, I suggest we prototype things before commiting to them.

> Chris Gray 

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods