On 1/16/06, Anton Oussik <[EMAIL PROTECTED]> 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) _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
