[crossfire] Moving server towards a modularized system?

[Miguel Ghobangieno]

That is what the hurd project thought at the begining,
the reality is diffrent.

--- tchize <tchize at myrealbox.com> wrote:

> 
> > 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
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com