[crossfire] Moving server towards a modularized system?

[Yann Chachkoff]

> Except that you are not working on one section of the
code, you are restructuring the whole server into
diffrent modules. This means that if you develop in
cvs there will be breakage with any and everyone else
as you sweeping edits touch every facet of the glory
that is crossfire.

Well, the required editing is, for the most part, moving existing code rather than change it. Algorithms will stay the same, execution paths as well, etc. What will change is the way various functions are called - so for example, calling "apply(this_object)" would become "this_object->manual_apply(this_object)" (This is only an illustration :)). Only in a few cases will new code be needed - mostly to bind the modules content to the code.

So basically, you'd expect problems in:
- The module loading/unloading (a clearly separate, specific piece of code);
- Improperly converted calls (which can be avoided if we're careful enough).

So no heavy breakage is expected.

> The C in CVS may mean concurrent but it doesn't mean
perfect.

I never said the contrary. It just means that no, even a refactoring of that scale wouldn't block the whole project for months, that's all.

> If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog?

I think all Crossfire coders perform quite some tests before committing to CVS - nobody would want to be responsible of severely damaging the server. Simply understand that coders are not perfect, and that they cannot think about all possible cases. To take a recent example, there was a library-related bug in the new plugin code that I didn't spot on time; was that because I didn't test that bit of code ? Of course not - but on the architecture I was trying it on, it simply didn't exist.

Also, let's not forget that the CVS codebase wasn't meant to be used on "production" servers: the CVS is (theorically) the repository in which the "work in progress" server code is stored. Stable versions are distributed in the various packages available on the SF website. Now, it is true that if some big changes are to be done, it would probably be a good idea to release a new "stable" version first, so that server administrators like you can get all the recent features without having to struggle through the possibly stability-threatening changes. 

Regarding possible performance issues, I think that there are ways to ensure that nothing noticeable happens. Most of the time lost would probably get when the plugin/module gets initialized and loaded - and that's unimportant for the running speed of the server.