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

2006-01-18 Thread 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?

2006-01-18 Thread 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


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

2006-01-16 Thread Yann Chachkoff
 Try not to dismiss things solely because they disagree with your opinion.

I dismissed a flawed analogy, based on wrong technical assumptions. It is not 
an opinion point, but rather the rebuttal of an out-of-topic flambait.

 Modularizing the server would create a ton of
problems, 

Tons ? Name them, then, and we'll have something to debate.

 breakage, 

Just as there is with *each* code change. Are you suggesting that we stop 
changing the code ?

 and solve nothing 

As I (and others) argumented, it eases a couple of development issues. It could 
be a flawed view - but then, demonstrate it, and suggest other solutions.

Note that those points weren't based on air, but on significant experience in 
other projects, not on taste or other egocentric or sentimental feelings.

 and add even less: it is busy work. If you must be busy be busy on some new 
 feature 

Given that you are not a coder, you have no right to decide for me what I 
should work on (Note that I usually don't follow such a philosophy - but since 
you expressed the exact same reasoning not so long ago, I find it appropriate 
to provide the same kind of answer now).

rather then scrapping the last 10 years of work (and that is what would happen 
if we seriously went on the modularizing war path).

Why ? I see a rant based on a pure sentimental feeling from somebody who has 
little knowledge of the Crossfire code, or of C coding in general. Provide 
technical arguments, and we'll have a serious discussion. If you cannot, then 
stop spamming the list.

Just as a side note, scrapping the whole code has never been the intend. Next 
time, try to understand the emails you read before flaming their content.

 Things you can help add:

Out-of-topic - we're discussing the pros/cons of modularization, not about your 
personal wishes about the code.


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


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

2006-01-16 Thread Yann Chachkoff
 Sorry, in the initial post I presumed it would be python, but a C plugin 
 seems like a reasonable idea.

Yep, I easily understand the confusion, given that for the most part, the 
Python plugin was the only one widely used (Actually, it is the 
Crossfire-Python bridge itself that is the plugin, not the scripts it allows 
to run).

 For one thing, I can't imagine a C plugin ever not 
being able to be installed (unlike python where people could be lacking the 
libraries)

Well, it really depends on what the C code requires as dependencies - the 
Python plugin has one with the python libs for example. But stuff that was 
initially in the server code would have no such external dependencies indeed.

 That said, trying to figure out what is optional or not is difficult.  I'd 
 venture to say a lot of people would say the random maps really are not 
 optional (or if those are optional, what else is optional, like shops, 
 monsters, etc)

Well, I don't think we should actually draw a line between what is optional or 
not in gaming terms, because basically nearly everything actually in the server 
code could be considered as core in that respect. 

On the other hand, I think splitting the code in logical entities, more or 
less independent of the others, would be a path of thinking to try. As such, 
random maps would appear as a good target for modularization, since it doesn't 
really depend on anything else, apart from very basical operations, and is 
called only at a few places. Alchemy would be another good candidate - both are 
very important in the game, yet are working very much like black boxes - 
complex code with relatively limited interactions with the rest of the code.

 I'd think that if there is a C plugin, aside from the different passing in of 
 the values, and using appropriate callbacks for functions instead of calling 
them directly, it could access the function data directly? Eg, it should need 
to do a plugin callback to set the dam of an object, it could just set ob-dam?

Theorically, yes: there's nothing preventing such a thing. Wrapping such access 
behind functions was basically to allow checking that the values passed were in 
the correct range, and to provide encapsulation of the data (so that a plugin 
wouldn't get tempted to directly change fields it wasn't supposed to change 
without a high risk)

 That said, the plugin itself won't fix all the ills.

That's true. It is a way to make some things easier, but it is definitely not a 
magical answer to all problems. My opinion is that it would make the code 
cleaning/maintenance easier, but it will certainly not do that maintenance by 
itself.

 To do that, more radical changes are needed in the basic functions as is, and 
that will break things.

Sure ! But I think such changes would be easier to make if the code was, in a 
way or another, split into smaller entities, so that they affect only a 
limited part of it. And indeed, a lot of functions would benefit from some 
in-depth rebuilding. Also, part of the problems of code debugging/maintenance 
come to how things are distributed all around the code - finding where to 
add/change things is a rather complex task. Making small changes to make the 
code more readable and editable would thus be another important point to 
achieve, IMHO.

 all that said, I do think it is fair to discuss other work to be done - if 
 you have limited resources, it makes sense to discuss where those resources 
 go. 

Indeed, it does - as long as it stays a reasoned discussion attempting to find 
the best solution, and not a collection of ignorant rants and ridiculous 
analogies. I'm tired of having to read such useless things, which 
(un)surprizingly always come from the same person. 

 Yet at the same time, given this is a volunteer project, one can't really 
 force anyone to do anything.

Yes, although I understand the urge that many people have to see some 
funny/interesting ideas implemented. Simply, there is a civilized way to ask 
for those, a way that unfortunately not everybody seems to have understood.



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


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

2006-01-16 Thread Miguel Ghobangieno
I suggest you not implement a huge worthless code
change that is nothing but busy work. I reject your
assertion that cave's analogy is flawed as it is not.
If you want to code code something new useful rather
then breaking the server as is what will happen if you
go forward with this plan. You also will be holding
off any new large codechanges for months as they wait
for you to be done with this not-needed reshuffling.

--- Yann Chachkoff [EMAIL PROTECTED]
wrote:

  Try not to dismiss things solely because they
 disagree with your opinion.
 
 I dismissed a flawed analogy, based on wrong
 technical assumptions. It is not an opinion point,
 but rather the rebuttal of an out-of-topic flambait.
 
  Modularizing the server would create a ton of
 problems, 
 
 Tons ? Name them, then, and we'll have something to
 debate.
 
  breakage, 
 
 Just as there is with *each* code change. Are you
 suggesting that we stop changing the code ?
 
  and solve nothing 
 
 As I (and others) argumented, it eases a couple of
 development issues. It could be a flawed view - but
 then, demonstrate it, and suggest other solutions.
 
 Note that those points weren't based on air, but on
 significant experience in other projects, not on
 taste or other egocentric or sentimental feelings.
 
  and add even less: it is busy work. If you must be
 busy be busy on some new feature 
 
 Given that you are not a coder, you have no right to
 decide for me what I should work on (Note that I
 usually don't follow such a philosophy - but since
 you expressed the exact same reasoning not so long
 ago, I find it appropriate to provide the same kind
 of answer now).
 
 rather then scrapping the last 10 years of work
 (and that is what would happen if we seriously went
 on the modularizing war path).
 
 Why ? I see a rant based on a pure sentimental
 feeling from somebody who has little knowledge of
 the Crossfire code, or of C coding in general.
 Provide technical arguments, and we'll have a
 serious discussion. If you cannot, then stop
 spamming the list.
 
 Just as a side note, scrapping the whole code has
 never been the intend. Next time, try to understand
 the emails you read before flaming their content.
 
  Things you can help add:
 
 Out-of-topic - we're discussing the pros/cons of
 modularization, not about your personal wishes about
 the code.
 
 
 ___
 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