<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: DevMUD: Inheritable modules -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Fri, 30 Oct 1998 22:30:24 -0800 -->
<!--X-Message-Id: 199810310625.AAA03994@dfw-ix14.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 3.0.5.32.19981030121858.008fe140#mythicgames,com -->
<!--X-Reference: 19981030134044.A22629#flagstaff,Princeton.EDU -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: DevMUD: Inheritable modules</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00616.html">Previous</a>
| <a href="msg00618.html">Next</a>
]
Thread:
[ <a href="msg00851.html">Previous</a>
| <a href="msg00684.html">Next</a>
]
Index:
[ <A HREF="author.html#00617">Author</A>
| <A HREF="#00617">Date</A>
| <A HREF="thread.html#00617">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: DevMUD: Inheritable modules</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: DevMUD: Inheritable modules</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Sat, 31 Oct 1998 01:26:16 -5</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On 30 Oct 98, Adam J. Thornton wrote:
> I very much like the idea of doing the core of the server in ANSI C with
> POSIX functions, and implementing (as a module, of course) an OO scripting
> langage for actual world development on top of it.
>
I think the idea of a something called the core is sort of a cop out
in designing a system. Basically it's a blackhole, where one can
dump anything with out really thinking about interface.
Some may also know this as the blob phenomenon, where a single
amorphous controller class or system management module monopolizes
all the processing. The surrounding modules become little more than
a means to encapsulate data and ultimately serve the blob.
One solution is to slow down, stop, and refactor the responsibilities
of the disparate functions which have been tossed into the blob.
Then again maybe I'm just scared... It's hard to kill the blob. ;)
> That's mostly because I understand C a lot better than I do C++; this is
> basically a personal aesthetic judgment on my part. However, I think the
> core will tend to be smaller, cleaner, and easier to read if we stick with
> C.
I prefer C++ because of aesthetics. :) Different strokes. But I
see no reason why each component couldn't be written in C or C++.
There does seem to be some agreement here that each component module
expose itself in terms of a C call linkage structure.
> Then we have the problem of what belongs in the core. My candidates are:
> Networking primitives (however, leave authentication et al at a higher
> level, whether in C or the MUD language) (what I've done in the system I'm
> working on is to have a per-connection value that represents what
> crypto/authentication mechanism that connection uses, so that's really a
> protocol design issue), and the notion of connection and thread-or-process.
> I think there ought to be a one-to-one thread-to-connection mapping (there
> may of course be non-connection oriented threads going on, but each
> connection presumably requires its own thread, unless we want to make the
> I/O model nonblocking, which I think will get unwieldy for large numbers of
> players). Also message queues of some sort to handle the data that each
> connection is transporting.
Let's just say there are a number of modules that need to be in place
to get "core" functionality. Each of them should be designed
independently of each other but expose an interface.
A network module should be able to handle requests from any module,
not just a centralized monolithic core. The network module could
be reactive, that is only respond to requests, like polling, input
output, closing connection, etc). A reactive network module demands
that the module requesting information (assume the core) know all
about how input, output, poll, sequencing is done. OTOH a proactive
network module would both send messages and respond to messages
to any interested modules. The only thing required is that the
network module know who he will be talking to and who he will
be responding to at runtime. I think a each module should have it's
maintain it's own configuration data.
I think all that should be required of the core is that it read a
configuration, load and startup all the modules. At that point the
core is done and goes asleep.
> So basically the core (in my idea of it) would not do much except handle
> connections, broker them, and multiplex/demultiplex the data going through
> them. This is going to be kernel-like, so it's not really that important
> to be able to dynamically load it or unload it--I can't imagine a MUD that
> did not provide these services. And I think this bottom layer would be a
> couple thousand lines of C: quite small.
I see a network module as an independent component that behaves
just like a smart realtime device. A useful way to visual it
is like a row of local connections all controlled by the network
module. Now load a another network module called the ipc_network
module. No we have another network running on the same server sending
and receiving messages from us. Perhaps this secondary process
is using a core which is configured to run ipc_network only.
Let's load a third network module, called the rpc_network module.
Now we're receiving and sending messages to a network running
on a secondary server. There's more. Let's load a network module
called playback. Playback simply reads and writes dozens
(nay hundreds) of local files that look suspiciously like user input
and output logs. We've now got a regression testing mechanism or a
way to simulate fictional server loads. Wait I'm not done yet...
Perhaps I don't want to load the network module at all. I load
my console module. Now I'm the only one who can play and develop.
And before I leave off, how about if I load the the playerbot
module, in addition to my network driver, which wonders about the
mud asking everyone and if they've seen a mythical place
called Midguard. What about network indirection modules, where you
can play muds within muds within muds.... ok ...enough for now...
I'm thinking totally independent components here.
Any thoughts.... :)
--
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00597" HREF="msg00597.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></STRONG>
<UL><LI><EM>From:</EM> Darrin Hyrup <shades#mythicgames,com></LI></UL></LI>
<LI><STRONG><A NAME="00599" HREF="msg00599.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></STRONG>
<UL><LI><EM>From:</EM> "Adam J. Thornton" <adam#phoenix,Princeton.EDU></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00616.html">[MUD-Dev] Re: DevMUD Objectives?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00618.html">[MUD-Dev] Re: Recursive look</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00851.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00684.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00617"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00617"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Why modules? (Was: Inheritable modules)</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00701" HREF="msg00701.html">[MUD-Dev] Re: Why modules? (Was: Inheritable modules)</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 03 Nov 1998, 04:49 GMT
</LI>
<LI><strong><A NAME="00691" HREF="msg00691.html">[MUD-Dev] Re: Why modules? (Was: Inheritable modules)</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 03 Nov 1998, 00:23 GMT
<LI><strong><A NAME="00704" HREF="msg00704.html">[MUD-Dev] Re: Why modules? (Was: Inheritable modules)</A></strong>,
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Tue 03 Nov 1998, 05:54 GMT
</LI>
</LI>
<LI><strong><A NAME="00851" HREF="msg00851.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
James Wilson <a href="mailto:jwilson#rochester,rr.com">jwilson#rochester,rr.com</a>, Sun 22 Nov 1998, 23:04 GMT
</LI>
</ul>
</ul>
<LI><strong><A NAME="00617" HREF="msg00617.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 31 Oct 1998, 06:30 GMT
</LI>
<LI><strong><A NAME="00684" HREF="msg00684.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Mon 02 Nov 1998, 10:41 GMT
<UL>
<LI><strong><A NAME="00692" HREF="msg00692.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Tue 03 Nov 1998, 00:24 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00681" HREF="msg00681.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Mon 02 Nov 1998, 10:14 GMT
</LI>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00608" HREF="msg00608.html">[MUD-Dev] Re: DevMUD: Inheritable modules</A></strong>,
The Arrow <a href="mailto:arrow#trelleborg,mail.telia.com">arrow#trelleborg,mail.telia.com</a>, Sat 31 Oct 1998, 00:17 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
