Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit : > Frankly, I have to agree with mikee to some degree on this point. I > generally have little trouble finding something after a combination of > getting a feel for the code, which I have gotten pretty good for a while > now, as well as skilled grepping. > "Finding something" is not really that difficult. However, adding new things often is, because it is not uncommon to have to modify the code at several different places. I see this as inherently bad - if I want to implement a new object type for example, I'd prefer putting its whole code in a single place than having to edit several source files (some being in common/, others being in server/).
Of course, a skilled coder that has got a good knowledge of the Crossfire code generally has little difficulty to find its way through the code - but not every contributor can/wants to afford the time required to get that in-depth knowledge of the code; besides that, having to play with grep to find the relevant piece of code is already a failure in itself, IMHO: if even somebody used to the source has to rely on a search engine to find its way through it, can we consider there is no problem ? > However aside from some things like this, I do find modularization can > have merits, it just depends on 1) How much effort it takes to > modularize, > It actually depends on the level of control you want to grant to the plugins. The most extreme case would be to export all the functions currently in the code - to do that, you'll have to provide a wrapper for each function you want to export. That's a lot of functions, but let's not forget that a significant part of those are only used by specific pieces of the code, so the actual useful number is definitely lower than that by a significant margin. As for the code located in the module itself, there would be little to change; at most, the function names being called (to call the wrappers instead), and the initialization/termination code (which will quite probably be the same in most cases). > 2) How effective the modularization API is designed (i.e. > currently the existing plugin API is vastly insufficient for server > modularization) > I think it is unsufficient for two reasons: (a) The API provided to plugins is not complete enough; (b) There are no ways for a plugin to interact with the server outside of the local/global events. I think (a) can be completed as modularization advances - if I tried to make a plugin out of alchemy, I'd check all the "external dependencies", then move them into the plugin API if required. It however means that the API will be an evolving target as long as modularization is in its early stages, though. As for (b), as I said earlier, I think it can be solved by offering to plugins the possibility to hook themselves to some often used functions in the code. In such a case, I think the plugin code should get hooked by callbacks contained in objects whenever possible (so, instead of calling apply(op) and make a switch(op->type) in apply, the specific behavior of op would be directly bound into the object as a callback and called by op->apply(op)). In that scenario, there would be no overhead involved when compared to the current situation - it would basically replace a switch statement by a function call. > and 3) Where we draw the line of what to modularize. > I'm not sure a line has to be drawn to what/what not modularize. I think a more important question is: to what level should the modularization take place ? I don't think there are simple answer to those questions. I'm not even sure answering them in a definitive, strict way is really required. > Personally, I don't think we should modularize very much, but if the API > is good enough (which I would likely be picky about myself), then it > might be worth doing for a limited number of things. > > Indeed. On this example, IMHO random maps are not optional, as they are > essential to some quests, and also soon would be used by land plots > (though land plots would in my opinion be a relatively good thing to > implement as an optional-but-defaultly-on C plugin) > Note that "optional/necessary for some quests" should not be a critera for modularization IMHO, because it is one you can use to justify nearly every function implemented in the game. On the other hand, the "optional/necessary for the server to run" sounds much more relevant. Can the server work without random maps ? Of course - it simply means that the maps using that feature will not work, but the others will be completely unaffected. It has no impact on the gaming rules, and no influence on the characters. > Personally, I think that a C plugin interface for modularization, it > should provide full direct access to the data, though recommend use of > wrappers functions unless you know it's safe. > Nothing currently prevents a plugin to modify the data it has access to directly - but of course, that's unsafe access, so if the plugin makes a bad modification to the data, or forgets to notify the server of it if necessary, then it will probably crash the server. Accessing data directly or through wrappers is basically a tradeoff between performances and security. In the case of modularization of the existing code, I'd say that direct access wherever possible should be kept - accessors for such data modifications would probably be used only for debugging purposes (as a wrapper can check if the data modification is "legal" or not, and thus can help detecting a whole range of errors). -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0
pgplhDMaZHrd5.pgp
Description: PGP signature
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire