[MUD-Dev] Custom Server Roll Call?

[Emil Eifrem]

At 07:51 AM 5/15/99 , Chris Gray wrote:
>[Emil Eifrem:]
>> 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.

So basically enforcing this would mean I'd have to use of some kind of
preprocessor that confirms that all invoked exported functions have a
corresponding definition somewhere in some other module? Unfortunately,
that's the kind of extension I would much rather avoid. I think I have
achieved the same effect with my "exported functions?"

>
>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.

-nod- I have the bad feeling that in the end, I will be using strings for
my events anyway. :(

I guess this would work. My initial response was "what if/when DB module in
this example does not emit a response event, the whole command handler
would freeze!" But that's really no different than from using normal method
calls; the way I have it now, any method can block and freeze the mud if it
wanted to.

I'm going to have a look at this alternative. One concern (as you pointed
out) is performance, this will need to happen literally thousands of times
per second, probably more by a magnitude. And suspending-resuming threads
in Java is not only discouraged, it's a resource-eater as well.

>
>> 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. 

Right now, only the module that defines a class can do any operations on
it. Actually, that's the way it will stay whether I like it or not, it's
just the way this type of class unlaoding works in Java. This may be for
the good in most cases but it would be nice to somehow share common data
types without having to resort to putting them in the kernel.

>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.

That's what it's like in the current version. I'm not actually passing
along a Connection object with my NETWORK_NEW_CONNECTION event, I'm passing
along an int that represents an index in the Network module's internal
connection list. This works out ok as far as connections and similar go.
But it makes it practically impossible (or at least very awkward) to have
for example a Creation module that is responsible for creating objects of a
complex class (Player) that other modules can use.

[snip problems with devmud]
>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.

I would really want to have basically everything contained in reloadable
modules. I'm just so hooked on the "detach;compile;attach new" approach to
a mud that has been repeated here so many times. (I'm also, btw, coming
from a 100% hardcoded background (ROM) with a server that basically
requires rebooting for every little change. Much like that favorite
operating system we all love to hate.) I may ultimately end up with a
server consisting of two modules: network and world, where world is an
entire mud minus networking.

[ - - - - 
Emil Eifrem [emil at prophecy.lu || www.prophecy.lu/~emil]
Implementor of Prophecy [telnet://mud.prophecy.lu:4000]
Coordinator of the Jamu effort [http://www.javamud.org]
                                              - - - - ]



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