[crossfire] Moving server towards a modularized system?

[tchize]

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

i see the exact opposite of behaviour at work. Project initiated in a modular 
way, or migrated to a modular approach are easier to manage for the following 
reasons
1) You don't need to have knowledge of how the whole code works to be able to 
work on parts of it
2) You can isolate changes in only a part of the code
> 
> 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.
> 

Architecture must be handled from the very beginning and currently there is no 
architecture design on crossfire project. A way to structure things here is 
suggested. This may not be the best approach, but it's far better then what 
we currently have. And nobody in the last year did propose anything to fix 
architecture problems in crossfire.

And in modularized projects, the interfaces between modules are not always 
clear, they are not fixed and would probably never been. Some code migrate 
from one module to another after experience show it is needed nearer to the 
core, or on the opposite, it get further from the core because it is not as 
multipurpose as we may have thought in the begin. Some modules sometimes get 
gathered as a unique module.  Some other gets splitted in sub modules. That's 
the lifecycle of a project.  It works, and well. Yes sometimes there are 
clash, sometimes a very big change in a module is a pain in the ass for all 
people using the modules. But considering the gain, in development speed, in 
code learning curve and bugs hunting, it is clearly worth it.

You argue a change in 'core' could interfer with 'weather' and you don't want 
to fix weather if it gets broken by that change in core? Well i claim, with 
current organisation of code, a change *anywhere* in code (not only what we 
could define as core) can break the weather. (Or potentially break anything 
else). That is something a modularized approach tends to prevent as much as 
possible.  And am not speaking of compilation here. Compilation problems are 
easy to solve.

You could argue, currently, you can't make a change in core that would make 
weather uncompilable, which with a plugin system could be possible. But, this 
is not a difficult fix, the most difficult bugs to fix are those which let 
the code compilable but with subtle invalid logic.  And the last one happends 
a lot in crossfire.

regards