Re: Re: Re: [crossfire] Moving server towards a modularized system?

[Yann Chachkoff]

 Indeed. Just because the server can be modularized thus blocking any other 
 new development whilst that
takes place doesn't mean it's a good idea. 

There is no reason to block any other development. I suppose you know that the 
C in CVS means Concurrent ?

 I for one frown on the idea of making the server slower 

There is no reason that it would be slower than it is now. There are no reason 
for a modularized system to be slower than the current version. The only 
overhead would be when connecting callbacks to objects - and that's hardly 
something you'd notice, unless if you're running Crossfire on a [EMAIL 
PROTECTED]

 and blocking other development.

I think I already said it, but there is no reason to block other 
developments. Everybody who has already worked in large-scale software 
projects knows that parallel development on different parts of the code is a 
rather common practice. 

That you believe that only a single task can be performed at once on something 
like the Crossfire code shows that you urgently need to get better informed on 
software development/engineering techniques and more generally on modern 
teamwork methods.

For what is worth, I could already be working on a code prototype on my 
personal workstation - would you ever notice it before I submit a patch ? Would 
it prevent somebody else to add something in the code in the meantime ? The 
answer to both of those questions would appear obvious, I think, to every 
reasonable person.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: Re: Re: Re: [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 [EMAIL PROTECTED]
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@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 

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire