[crossfire] Moving server towards a modularized system?

[Brendan Lally]

On 1/16/06, Anton Oussik <antonoussik at gmail.com> wrote:
> On the other hand modularising the code will result in many changes,
> may introduce new bugs into the code, and is in general a lot of work
> whilst the benefits are questionable (this will only be useful if core
> is really small and most things are out in modules which can be
> configured at configure stage). If someone has a desire to do all that
> they are welcome to (it is an open source project :-) ), but in my
> opinion implementing new features would be more beneficial to the
> project.

You forgot the other important point, modularity reduces speed of
development, sometimes catastroptically, you only need to look at GNU
Hurd for an example of that.

It strikes me that crossfire is (still) not yet mature enough to have
a fixed interface to all the modules that would be used, only a couple
of months ago all the python scripts were broken by a plugin change,
and I know I for one wouldn't want to attempt to fix the weather
'module' the next time the interface to it was broken.

If there is going to be breakages, how about breaking the things that
are already obsolete? There is a lot of old code in crossfire that has
long since become redundent, which nonetheless increases complexity,
the most obvious of these (to my mind) are:
the original 'map' command, which doesn't support big faces at all.
code to convert spells into regular objects, which was a conversion
that happened years ago.
the gnome client, which doesn't work (ok, that's client side, but still)
stats support for the old skill system
polymorphism (most of it is #if 0'ed out, but I'd prefer removed completely)
32 bit exp support (surely no one still uses that?)
cfsndserver (it doesn't work)