[MUD-Dev] Dynamic Loading of Modules

Greg Munt greg at uni-corn.demon.co.uk
Fri Mar 20 21:50:24 CET 1998


On Fri, 20 Mar 1998, Niklas Elmqvist wrote:

> On Thu, 19 Mar 1998, J C Lawrence wrote:
>
> > On Tue, 24 Feb 1998 00:12:50 PST8PDT 
> > Niklas Elmqvist<d97elm at dtek.chalmers.se> wrote:
> >
> > > ...and all the functionality such as DB
> > > management, socket I/O and AI would be implemented in free-standing
> > > modules separate from the main executable (at least, I envisioned
> > > this in the beginning). 
> > 
> > Which abstraction is deeper than Cold (or any other that I know of)
> > has attempted.
> 
> Of course, this abstraction comes at a price. Since the modules are very
> decoupled and don't know anything about each other's existence, I need a
> decoupled way of allowing them to exchange information. I envision this
> mechanism as a request chain on which the individual modules can put their
> ear to and listen on (alternatively, register their interest in different
> kinds of requests to a request manager or something). 

Reading this made me think of Occam, for some reason...

Occam is a language used by transputers to achieve true parallel 
processing. They communicate through data channels, using the following 
syntax (from memory):

  To output data to a channel:

    CHANNEL ! DATA

  To input data from a channel:

    CHANNEL ? DATA

Each transputer runs a seperately compiled program. The programs 
communicate by passing data to a channel, which is then picked up by 
another transputer, which is waiting for data on that channel. 

In Occam, channels are implemented as datatypes, and can be passed around 
via function parameters, etc.

It may be worth looking into, I don't know. HTH, anyway.
--
Greg Munt, greg at uni-corn.demon.co.uk; http://www.uni-corn.demon.co.uk/ubiquity/
"Deliver yesterday, code today, think tomorrow."




More information about the mud-dev-archive mailing list