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

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

Vadim Tkachenko wrote:
> OK, take everything below not as attempt to be a smart<censored>,

It wasn't an attempt, I am a smartass... :^}

> 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.

Why forget it?  5 seconds is possible (speedy storage format, lazy loading
etc), but perhaps not desirable.  With server "migration" (distribution) it
_certainly_ is possible.

> > 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.

I dunno, If you are interested in coca-cola, then are one of the few lucky
ones to get a coca-cola T-shirt for free while waiting for the cola... ;) 
Actually it is used a lot in games, it's called a bonus level.

> > You can usually solve stuff in the design.  It's not like we are producing
> > 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.

YEAH!!!!!!!!!  And dynamic modular loading isn't it, as the analysis which
has been skipped could have shown.  You are currently designing "nothing".

> > 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?
> 
> I consider MUD server a full-fledged server.

Meaning you are going to be hitting the hardware?  One basic difference
between an OS and a mudserver (of many) is that without the OS the machine
is completely dead.  This ain't true if one mudserver is down.

> > Besides, if you hafta migrate state from one module to another, then why
> > don't you just migrate state from one server to another?
> 
> Was that a sarcasm I smelled? ;-) Why not, really?

Not sarcasm.  Server "state migration" does at least provide functionality
that is useful if you distribute the thing.  If you are so hung up on
downtimes, it will provide less downtime than moduleswapping... (not that I
think it is that important, mind you!)

> > 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.

I don't think so judging from what has been discussed. It's a component, not
really a library. Actually, it seem so tbe be a fairly detached and
selfsupplied component too. Or?

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

What is different is that it is stupid. Doesn't know it's environment.

> > 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.

But the interface needs a profile?  Approaches discuessed involved
handcrafting AFAIK.

> 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.

This has nothing to do with devmud-modules.  This is about structured
programming, modularization and OO.  There is currently no modularization,
there is only mechanisms without any analyzed need or requirements.  Thus
everything is grounded in "nothing".

> 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.

Ahh.. You aim for Java efficiency.. :-) I rest my case.

--
Ola