Re: Re: Re: [crossfire] Moving server towards a modularized system?
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?
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?
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?
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?
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
