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

[Chris Gray]

[Niklas Elmqvist:]

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

I had thought a bit about distributed stuff. One of my questions was about
whether there could be more than one DB module. Later it occurred to me
that if we have a big enough ID for entities in the DB, part of that ID
could specify which DB module supports the entity. Then, there is no
particular reason why a given DB module couldn't be just a network connector
to a real DB somewhere else. The latencies are a *lot* higher for those
entities, so caching in that DB module would be important. With those
latencies, it would become mandatory that multithreading be used, else
the whole server would hang while the remote DB provided something.

What happens if all of the DB modules aren't loaded, I don't know. Boom!?
Also, since entity ID's are stored in other entities, the mapping to
DB modules needs to be reproducible from run to run.

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

Providing a service that all modules can use is good. Adding overhead that
few modules would otherwise experience is bad. IMHO. We should look at how
many modules could make use of any core-provided queueing. If that number
is low, then forcing all to pay the overhead is probably bad.

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

No problem. I like that better than long lines and horrible linebreaks!

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

Smile. I like it too, of course. I should point out, however, that it
isn't the most powerful parser of the MUDs done by folks on this list.
Perhaps some of those folks will speak up?

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