> The harder part is to define what are the core/basic rules and what are > options.
Definitely. But I'm not sure such a definition is really needed. I think that if a functionality is clearly "optional" or isn't strongly tied with the rest of the code (as it appears to be the case for random maps or the weather system), then it should at some point be modularized. I'm not sure I'd like to see a "let's define what the core is" debate being open - it will lead to endless sterile discussions, because everybody has its own idea, and that there are multiple definition of what the core should include, depending on how you perceive the problem. > Taken to an extreme, you could say just write the entire thing in > python/perl/whatever. There isn't much a reason to do that (you're basically > re-writing anything, so only point would be to try to remain some > compatibility). The idea is not to "rewrite everything" - but to move existing code into plugins. Sure, the "accessors" will have to be rewritten - but there's no reason to rewrite the whole internal code logic to do such a move. > I personally don't see much reason to rewrite existing code that is working > fine as a plugin. There are just enough things that could be/should be done > than rewriting working code doesn't make sense. Again, there is nothing like rewriting whole sections of the code - only the "glue"-related stuff would have to be. As for the other important things to be done first, I tend to think that making the code more resistant and easier to debug should be our top priority, above the addition of new functionalities. In this respect, I think that modularizing things is a way to improve code maintainability on the long run. > 1) Speed - I'm sure the plugin is slower to some extent - ignoring the actual > plugin language, the fact that access of a lot of data is done through > callback functions vs direct access has to hurt a bit. This isn't an issue > if a plugin isn't used very often, but probably would become an issue if the > plugin is used multiple times every tick. I'm doubtful it hurts "a bit" - most of the overhead comes (a) from the analysis of the parameters passed by plugins to the server through va_args and (b) from the call to registered local plugin events. (a) is hardly an issue, even when dealings with hundreds of calls per second (unless we still want to consider 1997 machines as a relevant target architecture...). (b) is indeed an issue, as the server currently has to browse a list of objects to be able to call a plugin function. At some point, I think that besides the events currently available, plugins should be able to directly register callbacks that would be stored in lists and called at specific places in the code - "code events", thus, that would get called when a given server function is called, to modify or change its result. > 2) Complexity - I'd make the case that debugging very complex pieces is done > if all is in native C - don't have to debug accross languages, etc. Who said that the intend was to write plugins in another language than C ? It would be *possible* of course, but it doesn't mean that it is what we *want*. I don't see why you'd need to debug "across languages" - the base idea of a modularized system is to allow separate debugging of the modules and the core. And finally, given that the whole codebase is currently written in C, its modularization would lead to modules written in C as well. The whole question comes down to: "is a monolithic code easier or harder to debug and maintain than a modularized one ?". My personal opinion on this is that the answer is "it is harder". _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
