[crossfire] Moving server towards a modularized system?

[David Delbecq]

Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit :
> Frankly, I have to agree with mikee to some degree on this point. I 
> generally have little trouble finding something after a combination of 
> getting a feel for the code, which I have gotten pretty good for a while 
> now, as well as skilled grepping.

Crossfire is the only project i have worked with either on my spare time, 
either at work, which needs grepping in the code to understand it! This just 
proves how much a mess it is.

> 
> However aside from some things like this, I do find modularization can 
> have merits, it just depends on 1) How much effort it takes to 
> modularize, 2) How effective the modularization API is designed (i.e. 
> currently the existing plugin API is vastly insufficient for server 
> modularization) and 3) Where we draw the line of what to modularize.
> Personally, I don't think we should modularize very much, but if the API 
> is good enough (which I would likely be picky about myself), then it 
> might be worth doing for a limited number of things.
> 

1) It would be, in my opinion, a progressive effort. Modularize one piece, 
then another one then another one. This woudln't prevent current commiter to 
do their add-ons too.

2) modularization api should simply progress along with modules. If you need 
core to export something new, then simply have it export it. Please not i 
don't consider plugin based modules as the only solution. It would be good in 
the sense it force code to have clean way to access datas. To get back to 
provided example, what if modules whant to change object->dam? Well i would 
say then it must register a dam modifier methode to object :) Simply because 
you can't be sure another module don't want also to interfer with dam
imagine this rule "with this item weared, player does twice dam when standing 
on fire" and this one "this weapon does half damage when player is wearing a 
helmet" It's up to core to gather rules exception registered for object and 
do a calculation chain based on it. mdifying object->dam directly would then 
be dangerous :)

3) the line will be found in a progressive way. Depending on needs.

> Alex Schultz
> 
> Miguel Ghobangieno wrote:
> 
> >I have to do the same thing when I am adding things to
> >my perl rpg (which is not smaller in lines of code
> >then crossfire). It's not a big hassle, and how else
> >will the code know what's going on? Use grep.
> >
> >--- tchize <tchize at myrealbox.com> wrote:
> >
> >>Speaking of my experience with crossfire code. I
> >>have developped
> >>a few add-ons to crossfire in the past (don't
> >>remember the list). 
> >>From my point of view, adding new features in the
> >>code is currently 
> >>a pain in the ass. I have dropped features add-ons
> >>which took
> >>me lots of time simply because it has become nearly
> >>impossible to find 
> >>something in the code. 
> >>
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> 
> 

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Pingouins dans les champs, hiver méchant