[crossfire] Moving server towards a modularized system?

[Miguel Ghobangieno]

You haven't worked on many complex projects then. The
upset this will cause in crossfire development (and
devs will wait untill it's done before committing
again because they don't want their new code to be
broken) will be very large. I would like to see plots
etc in crossfire in my lifetime, your "AWSOME
KAWABUNGA!" idea of ripping apart the server will
stall development for no freaking reason except that
you think that you are above using grep.

--- David Delbecq <delbd at oma.be> wrote:

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