[MUD-Dev] Custom Server Roll Call?

[Chris Gray]

[Emil Eifrem:]

> The problem here is that generateEvent() just adds the DB_ISSUE_QUERY event
> to the event queue and then immediately returns. All the actual processing
> of the event is handled asynchronously, ie in one or more separate threads
> in the kernel. Sticking to my example above, this is a big problem for the
> Command module who just wanted to get an int representing the amount of
> swords in the DB. What should it do? Sleep until the DB answers with a new
> event? Continue processing other commands until the DB module answers --
> then, continue executing the sword-counting command?
>
> None of the above is viable. My solution was to introduce a second way of
> IMC, tentatively called "exported functions." (Horrible name for something
> in a Java server, I know.) The idea is to make it possible for a module to
> execute special, 'exported' methods in other modules. Probably the best way
> to explain this is to show an example:
>
> ---
> DBModuleInterface = getModuleInterface("database");
> int amountOfSwords = DBModuleInterface.issueQuery(query);
> player.println("There are " + amountOfSwords + " swords in the db.");

I think this is quite close to the issues that came up with devmud. I
haven't been on Jon's MUD for months, so I don't know if stuff is happening
there or not.

We had talked about ways of linking up an exporter of functions to importers
of functions, based on descriptions of their arguments and their names. Thus,
the type-safe aspect wasn't done by the implementation language, but rather
by the matching code. My Java isn't good enough to know whether you can do
this in Java or not.

You could handle it by just using your first, event-based interface. The
command code builds the DB request and emits it. The DB code receives the
request and processes it. It then emits a DB-response message, containing
an identifier that was also in the request message. Receipt of that
response wakes up the command module, which was in a form of sleep,
waiting for a message like that. I won't comment on the efficiency of
a scheme like this, but it ought to work. Unfortunately, this completely
bypasses your desire for language-enforced type safeness, since you are
doing everything with strings, which are not checked by Java, but only
by the module(s) that receive them. It sounded like you were already
using lots of threads, so having the command module asleep, waiting
for a response, shouldn't matter - it should still be able to run
other threads to handle further input.

> This may not sound like a big problem. But it is, believe you me. Let's say
> that I want to have a Player class that several modules are dealing with.
> For example, I used to have a "Creation" module, that was responsible for
> creating new players and characters (player = a rl-world person, character
> = a fictional person run by a player). I thought this was a neat idea, but
> in order to have the Creation module pass the newly created players and
> characters to other modules (say, the 'World' module and the 'Playermode'
> module) I would have to move the Player and Character classes into the
> kernel. Remember, classes created in the Creation module are only visible
> to the Creation module.

Indirection. You'll have to go back to the older form of using objects,
rather than the C++ form. *Only* the module that defines a class can do
any operations on it. Everyone else can just store and pass around
references to specific objects of those classes. Untyped pointers,
essentially. You could just use integers for them, but Objects are likely
easier. Will this make it awkward to do lots of things? You bet! And
inefficient.

Things like this were some of the reasons I was having trouble thinking
how to go much further with devmud stuff. Socket stuff and telnet stuff
were certainly separable. People then wanted to get into things that,
to me, were aspects of the scenario, not the server. We even had trouble
with a programming language, since the nature of the language is closely
linked with how you want to use it. I could make my AmigaMUD language
into a module, I think, but then anyone using it is constrained by the
nature of the language. This is only possible because almost all of my
MUD is softcode, using that language. Thus, my server doesn't know about
much other than the low-level database, player records, logging, etc.
It sounds like you want aspects of your scenario (as opposed to your
low-level server) to be reloadable modules. I don't really see a way to
do that cleanly.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev