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

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Vadim Tkachenko wrote:
> Ola Fosheim Gr=F8stad wrote:
> > Can someone please explain WHY dynamic loading is desired?  I haven't=
 seen
> > one good argument yet for why it should be dynamic.  People won't rep=
lace
> > their magic module twice a day. Probably not once a month either, a r=
eboot
> > once a month is quite good!
>=20
> One of other threads discussed the drawbacks of the downtime. From my
> standpoint, this is exactly it: the point of having the dynamic loading
> is to eliminate the downtime.

Is lag downtime? (clever question I guess)=20

(explanation: if it reboot causes 5 seconds delay then there will be no
difference from regular lag)

Anyway, the time for reboot can be selected using heuristics, and users c=
an
be given a subgame as a compensation... You can usually solve stuff in th=
e
design.  It's not like we are producing navigation systems for nuclear
warheads...

> It's a Windows world concept (don't start a religious war here, please)
> that you have to reboot as soon as you do anything more offensive than
> renaming a file.

Actually I think Unix was first ;)

> With a proper design (note, done once) it's possible to
> dynaload everything else up to dynaloader code, then you don't need to
> shut down the server to upgrade.

Well... Any OS is a dynaloader then I guess. Actually a MUD cannot do
without any modules, it'll freeze when you loose a module, so they better
swap fast, you need to migrate state etc etc.  How is this different from
loading a server?  (You do of course have a separate login-server so ther=
e
will always be someone answering the doorbell)

I think you take the OS metaphor too far...

Besides, if you hafta migrate state from one module to another, then why
don't you just migrate state from one server to another?

> > Here are some good reasons for making it static:
> >
> > 1. easier to implement
> > 2. more portable
>=20
> With the proper abstraction levels, it's not a problem. I don't see how
> the static module is simpler if the dynamic one is wrapped and has no
> clue about it being dynamically loaded at all. Take look at Apache
> design (I'm not saying it's done this way, though).

Can it be simpler than a library following language conventions?

> > 3. faster
>=20
> On startup? How many times do yo boot it?

No, runtime.
=20
> > 4. more likely to be reusable in other (non-DevMUD) systems
>=20
> Absolutely disagree.

A library requires no extra considerations from the caller.
Additionally if you use C++/templates or similar compiletime
strategies then it can assume less about it's "neighbours"...

Yet another reason:
7. Less room for human error in the interfacing.
=20
> So you were off 7.36% ;-)

I know, I figured I had to give you some slack.

--
Ola