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

[Vadim Tkachenko]

Ola Fosheim Gr=F8stad wrote:
>=20
> 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 r=
eplace
> > > their magic module twice a day. Probably not once a month either, a=
 reboot
> > > once a month is quite good!
> >
> > One of other threads discussed the drawbacks of the downtime. From my
> > standpoint, this is exactly it: the point of having the dynamic loadi=
ng
> > is to eliminate the downtime.
>=20
> 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)

OK, take everything below not as attempt to be a smart<censored>, but as
attempt to resolve the complicated issue. I'm not sure that I'm right
everywhere, so let's get back to business.

Seriously, I don't believe that you will have reset time even close to 5
seconds. On the other hand, the lag can get up to minutes sometimes, but
that's something you can't control, so forget that.

Reboot/restart time includes:

- Time to shutdown cleanly, if it's not a crash.
- Time to perform initial checks, and additional to thoroughly check the
storage system integrity if a) there was a crash b) storage system
doesn't support transactions.
- Time to start all the services (like acceptors, storage system, you
name it)
- Time to load the world context (can be somewhat reduced if there are
shared world contexts for different users who happen to be in the same
areas of the world, if made on login instead of startup)

> Anyway, the time for reboot can be selected using heuristics, and users=
 can
> be given a subgame as a compensation...

As if you're interested in Coca-cola, but the store gives you Pepsy? I'd
do it once (for some reason hate Pepsy), but not more than once.

> You can usually solve stuff in the design.  It's not like we are produc=
ing
> navigation systems for nuclear warheads...

Right, but with a concept and team size like this you have to eliminate
every problem imaginable BEFORE you encounter it, at the design phase.

[religious war skipped]

> > With a proper design (note, done once) it's possible to
> > dynaload everything else up to dynaloader code, then you don't need t=
o
> > shut down the server to upgrade.
>=20
> 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 bett=
er
> swap fast, you need to migrate state etc etc.  How is this different fr=
om
> loading a server?

I consider MUD server a full-fledged server.

> (You do of course have a separate login-server so there
> will always be someone answering the doorbell)

That is a good idea. Actually, I prefer to handle not only login, but
all security related issues in the separate module, preferrably on the
other computer.

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

Well...

> Besides, if you hafta migrate state from one module to another, then wh=
y
> don't you just migrate state from one server to another?

Was that a sarcasm I smelled? ;-) Why not, really?

> > > Here are some good reasons for making it static:
> > >
> > > 1. easier to implement
> > > 2. more portable
> >
> > With the proper abstraction levels, it's not a problem. I don't see h=
ow
> > 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).
>=20
> Can it be simpler than a library following language conventions?

It _is_ exactly a library. After you resolve the module (which you have
to do anyway, say, in C[++] it's obtaining a pointer), you don't have to
specifically engage anything special. Or, you can have a wrapper
handling the dynaload stuff.

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

Well, arguable. You're right in terms of method call timing, but what
about a configurability? And, rarely performed operations?

> > > 4. more likely to be reusable in other (non-DevMUD) systems
> >
> > Absolutely disagree.
>=20
> 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"...

As I tried to show above, there's no need for the actual business logic
modules to care about the dynamic loading at all, except properly
resolving the module and holding a reference to it while it's still
active. I don't see, though, how is it different from the regular
pointer or file handle.

> Yet another reason:
> 7. Less room for human error in the interfacing.

Not quite. Again, with a proper design, you will have:

Technically speaking: isolated layer, relatively simple, easily
debuggable.
Psychologically speaking: isolated layer, interesting to some particular
people, who will eagerly contribute to _its_ development just because
it's interesting to them, and nothing else.

There's one more unrelated thing:

My experience shows that if you have a big system and try to
improve/replace/bugfix some minor module in it (not necessarily "module"
we were talking about above), and it's broken, it's much easier to find
the bugs (provided that the whole thing was good enough before doing
that) or undesired side effects, just because it's obvious where is the
problem - in the changed module. There are just too many things which it
may break so it becomes much easier to track it down, and then to fix
it.

So I don't think dynaloader is going to be a pain in the neck. We all
use it in Java all the time and don't even notice.

> Ola

--=20
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are