<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list) -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Thu, 19 Mar 1998 19:42:50 +0000 -->
<!--X-Message-Id: 199803191942.LAA34273#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: Pine.SOL.3.96.980224080855.19470A-100000#licia,dtek.chalmers.se -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the lis</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.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="msg00763.html">Previous</a>
| <a href="msg00765.html">Next</a>
]
Thread:
[ <a href="msg00575.html">Previous</a>
| <a href="msg00787.html">Next</a>
]
Index:
[ <A HREF="author.html#00764">Author</A>
| <A HREF="#00764">Date</A>
| <A HREF="thread.html#00764">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list)</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list) </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Thu, 19 Mar 1998 11:42:40 -0800</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Tue, 24 Feb 1998 00:12:50 PST8PDT
Niklas Elmqvist<d97elm#dtek,chalmers.se> wrote:
> On Mon, 23 Feb 1998 coder#ibm,net wrote:
>> On 20/02/98 at 12:43 AM, Niklas Elmqvist <d97elm#dtek,chalmers.se>
>> said:
> As I said earlier, I am aiming to decouple the actual core server
> from the world processing routines. Ideally, the main server would
> not even *know* it is running a MUD, it would be sort of a
> general-purpose core...
You have loosely described the general purpose network server espoused
by such as the ColdX project. Cold is currently being used to server
MUDs, web sites, as an SQL database frontend (for web) and otehr
purposes.
> ...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.
> I mentioned this to a RL friend of mine, and
> he pointed out that it all sounded very much like conventional OS
> architecture, especially like the module system of Linux kernels.
I should point out that the original version of Shades was written to
run on a DEC PDP-11. In truth Hazeii hacked RMS to be the MUD (mainly
the command interpreter) so that effectively the OS _was_ the MUD.
> In essence, what I discovered (to myself, that is, this is no doubt
> old news to some people) was that I could compile the core server
> with a base class with very little functionality, call it aClass,
> which called a factory function in a shared library, returning a
> pointer to an aClass object. Then, in the actual shared library
> (which is linked in with the main binary at run-time) I instead
> return an instance of a class called bClass, which inherits from
> aClass but which is totally unknown to the core server. Best of all,
> it works! That is, when I call the Execute() member function on the
> aClass handle in the core (which, unbeknowst to the core, points to
> a bClass object with redefined Execute() function), the correct
> Execute() function is called, that is bClass::Execute().
<bow> Cute. Note that the vtable handling could easily get very
messy, especially if you abstract heavily, go for multiple
inheritance, or any of the nastier virtual structures.
What platform/compiler BTW?
> Now, if aClass and bClass had been part of the same binary, I would
> not have been surprised. In fact, as you probably all know, this is
> called late binding in the O-O community and is an important feature
> of all serious O-O languages. However, what surprised and delighted
> me is that late binding *still* works even though the core and
> shared lib described above are separately compiled, and the bClass
> is totally unknown to the core! In my eyes, this is the ultimate
> test of late binding, and G++ pulled it off nicely! Incidentally, a
> friend (the one mentioned above) later reported that this is
> impossible in Windows-style DLLs.
Yup. The features behind this working are that the name mangling and
vtable manipulations remained consistent.
> If you are wondering what the fuss is all about (or why this posting
> is getting so long), let me just say this: One application of this
> could be an Event class (in an event-driven system), whose base
> class is known to the core server (allowing for it to check the
> priority and expiration of the event, among other things), while the
> modules can inherit from the base class and redefine it to suit
> their particular needs. I also plan on using this technique for
> Handler objects which take care of things such as socket I/O,
> parsing, DB managment, etc, and the good thing about it is that I
> thus will be able to attach and detach the modules at run-time (to
> remedy a bug, for example). If the base classes are correctly
> implemented, the core will never even have to be recompiled and thus
> never rebooted (not accounting for fatal bugs, that is <g>)!
You're going to need a very clean connect/disconnect model (and likely
require single-threading unless you want to be excessively
entertained) to ensure that no code points are in or about to enter a
modeule which you wish to remove, or retain state data, or
back-references (such as instances) for the about-to-be-removed
module.
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00787" HREF="msg00787.html">Dynamic Loading of Modules</A></strong>
<ul compact><li><em>From:</em> Niklas Elmqvist <d97elm#dtek,chalmers.se></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00574" HREF="msg00574.html">Dynamic Loading of Modules (was: Back on the list)</A></STRONG>
<UL><LI><EM>From:</EM> Niklas Elmqvist <d97elm#dtek,chalmers.se></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00763.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00765.html">Re: [MUD-Dev] Balancing Addicts -> soft vs. hard enforcement</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00575.html">Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00787.html">Dynamic Loading of Modules</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00764"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00764"><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><A NAME="00533" HREF="msg00533.html">Back on the list</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Fri 20 Feb 1998, 08:38 GMT
<UL>
<LI><strong><A NAME="00564" HREF="msg00564.html">Re: [MUD-Dev] Back on the list</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 23 Feb 1998, 19:13 GMT
<UL>
<LI><strong><A NAME="00574" HREF="msg00574.html">Dynamic Loading of Modules (was: Back on the list)</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Tue 24 Feb 1998, 08:19 GMT
<UL>
<LI><strong><A NAME="00575" HREF="msg00575.html">Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list)</A></strong>,
Vadim Tkachenko <a href="mailto:vadimt#4cs,com">vadimt#4cs,com</a>, Tue 24 Feb 1998, 08:42 GMT
</LI>
<LI><strong><A NAME="00764" HREF="msg00764.html">Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list)</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 19 Mar 1998, 19:42 GMT
<UL>
<LI><strong><A NAME="00787" HREF="msg00787.html">Dynamic Loading of Modules</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Fri 20 Mar 1998, 11:39 GMT
<UL>
<LI><strong><A NAME="00797" HREF="msg00797.html">Re: [MUD-Dev] Dynamic Loading of Modules</A></strong>,
Greg Munt <a href="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</a>, Fri 20 Mar 1998, 21:53 GMT
</LI>
<LI><strong><A NAME="00850" HREF="msg00850.html">Re: [MUD-Dev] Dynamic Loading of Modules</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Mon 23 Mar 1998, 19:14 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00800" HREF="msg00800.html">Re: [MUD-Dev] Dynamic Loading of Modules (was: Back on the list</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 21 Mar 1998, 00:54 GMT
</LI>
</UL>
</LI>
</UL>
</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>
