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

[Thandor]

On Sat, Oct 31, 1998 at 08:41:53PM -0600, Vadim Tkachenko wrote:
> 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)

I'll state my assumption here from the start - I assume that during the
reboot, we're keeping our connections alive. Simple because to do otherwise
tends to massively stretch out the reboot time due to the system getting
hammered with login requests, which slows the thing down, which only tends
to make the problem worse.

I've been throwing about 30s to reboot, I think that's probably reasonable,
given the hardware we have today, and the hardware we're likely to have in
a couple of years (which is at least how long it will take to finish the
DevMUD platform and then have somenoe build an actual mud on it, at least
in my opinion). Now, I'm assuming we're not going to crash often (which may
or may not be true), and so it's only scheduled reboots that we need to
take into account.

30 seconds downtime when you want to change a module. Even if that occours
once a month as Ola said, which I think is an overestimate of how often it
would happen, this still only means that we have 0.001% downtime. 
Personally, I think that it's not worth trying to recover this miniscule 
percentage of time if it means making any considerable effort.

After all, as I've heard several times, isn't the idea that modules don't
need to be changed, yuo do your changes in the internal mud language? At
least that's what I've been lead to believe.

> 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'm not sure whether you're for or against it here. :) To me asking for
coca-cola and getting pepsi would be like asking for UNIX and getting
linux. Sure linux isn't UNIX, but for all intents and purposes it is.

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

So whyare the nitty gritty details being designed before we answer the big
fundamental questions? The first question I think needs to be answered is -
what sort of muds/games/server systems do you intend to have running on top
of this? So far the only thing close to an answer that I've seen seems to
be "everything", which to me isn't much of an answer. I think the big
questions need to be asked and answered before we bother with the little
details of the format of module's announcing their presense to the rest of
the world.

> I consider MUD server a full-fledged server.

Then why isn't it being thought of like one? I doubt that in the early days
of apache they said they wanted to make some totally generic server, and
things just so happened to work out in a way that made it into a great web
server. Simiarly, I think we first need to look at what a mud server needs
to do, not how we're going to do it.

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

No, the question should always be why, not why not. Why not implies your
doing something just because it can be done, not because you have a purpose
in mind. If you can't answer why you're adding a feature, then I think the
feature is probably not one worth adding.

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

That's shifting the argument. There's no doubt that it won't be any slower,
and most likely will be slower if it were not a dynamically loaded system.
Whether it can be configured faster is a whole other issue, and one that
I'm not sure the dynamically loaded server wins either.

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

And won't you get the same with the library? Except you'll have any
problems pointed out at compile time rather than at run time when you try
to jam two pieces of the puzzle together that just don't fit.

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

I don't see how a dynamically loaded system is any different from a system
where you link in libraries at compile time here either. If the only thing
you change is a library before you recompile it, wont you know just as well
that any new problems lie in the library? I fail to see how dynamically
loading the module makes this situation any clearing than it already is.

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

Who says we all use java? :)

I don't see why dynamic loading is a requirement. It certainly is at least
some extra work, as the dynamic loader must be writen. If extra work is
being done, surely there should be some sort of payback for it. I can't see
where the payback lies - any advantages it might have seem to be offset and
then some more by the disadvantages. I admit I thought dynamic loading was
the way to go too ... but after thinking about it some more, I'm not longer
seeing why, other than the fact that it would be a cool thing to do. But
cool pieces of code make nifty geek toys, not good muds.

- Shane King.