[MUD-Dev] Re: Why modules? (Was: Inheritable modules)

[Adam J. Thornton]

On Sat, Oct 31, 1998 at 10:45:46PM -0500, James Wilson wrote:
> Writing modules in various languages does raise a lot of issues which I don't
> have an answer for. Can we really integrate a module written in Python with a
> module written in COBOL by having the kernel link up various extern "C"
> function pointers? Maybe. There may be some heavy lifting that has to be done
> for each language that is to interoperate; that is, perhaps C and C++ are the
> easiest to make interoperate, so we start with modules written in those. Then
> we look at Python interoperation, figure out how to make Python's memory
> management work with DevMud's, and distribute the proper magic to do so.
> Someone else looks at Perl, and James takes COBOL. I'm not sure this is
> feasible. We'd need to look at a lot of specific issues in great detail and
> design the kernel/modules appropriately.

This, I think, is where we should define the module API carefully and rely
on the bazaar model to fix it.  That is:

If the API is completely specified, then we implement what we want in C, or
C++, or whatever we use.  If someone wants a Perl interface bad enough, the
API is there, and they can figure out how to make it work.  If someone
REALLY wants a COBOL interface, there's enough information there for them
to build one.  But developers working on other things don't have to do it.
We do need to make sure we have a flexible enough interface that it is at
least possible to implement it in a bunch of languages.

This actually is what I'm planning on doing with the client for my own
project.  I'll define the protocol and write maybe a simple Win32 client
and a simple Unix/ncurses client.  Then I'll refer people who want more
client features to the protocol definition and tell them to look at the
code for the existing clients, and go forth and make it better.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman