[crossfire] Moving server towards a modularized system?

[Miguel Ghobangieno]

Well enjoy raping the server.
I'm retiring from CF untill a certain unnamed feature
I was promised 1/2 a year ago (no not plots) is in.
See you soon or never.

--- Yann Chachkoff <yann.chachkoff at myrealbox.com>
wrote:

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