tchize wrote: >> And for everyone out there currently using grep - download cscope and use > that >> - it is a vastly superior solution (even going to plugins or whatever else, >> cscope is a very handy tool - just run 'cscope -R' in the top level > directory. > > Am not sure it's a good idea to have de developper dependency on cscope or > grep.
But at some level, you will always have some dependencies on other tools - compiler, linker, editor, etc. I was mostly pointing out that if people are currently using grep, there are much better tools available. >> True, but that goes more back to my 'poor mans version' of plugins. >> >> At some level, I think a poor mans version with callback registration is >> actually more flexible. > > You'd have to issue a 'patch' if you want to add third party specific > features > (like a server having it's own crossfire -> html stats system). You'd have to > 'patch' the code if you want to disable compilation of a problematic piece of > code. True, but a plugin for object actions would be a pretty critical piece of code - you just can't disable the players from applying all items (or not compile that bit) and have a working system. Now the counter is that you'd just disable it for the specific bad object type, but then, if one plugin is covering 30 object types, that still isn't much an option. IMO, compiling/not compiling something isn't an issue - if something is so broken that it doesn't even compile, it should be fixed ASAP or be removed. the issue would more likely be disabling them once problems start, which would be same regardless of method used, but registered callbacks are probably easier. > >> One could have a registration function like: >> >> set_type_callback(object_type, event_type, callback()) >> >> The advantage of registration of that form (instead of true event plugs in > the >> object) is that adding new event type callbacks doesn't require any change > to >> the objects. > > What's the difference with > > set_type_callback(object_type, event_type, somePluginMethod()) ? > > the fact of adding plugin event to object instead of type, is just a > generalization of what is currently done for existing script and is needed to > keep backward compatibility (not to mention it also allow plugin to have some > methods triggered only on demand). Well, you can't have a single list of all the set_type_callbacks() unless all the functions are in the same module. For example, you can't have any such callbacks in the server code if they reference functions in plugins that are called later. Likewise, for the plugin itself, it will only know about the functions in the plugin itself. This isn't directly a problem except that these callbacks would be spread across several plugins, which makes finding the actual details more difficult (have to do a grep to see which file is registering that callback). For most plugins, that probably isn't a problem - if one were to think of the random map code, it really only needs to register one callback, so big deal. OTOH, the random map code is already pretty well modularized, so I don't see much point to convert that to plugin logic. > > Moreover before thinking of the specific ways to modularize things, questions > to be answered must be > - Do we want a modularized system? > - If yes, who would lead this process, how will he lead this, and who would > team with him. I think the term plugin vs module probably needs to be clarified, as well as clarification what approach we are really taking. To me, module is like the .a files currently used (random maps, socket, etc) - code is logically grouped in one place, but linked in at compile time. plugin is code that isn't loaded until run time by explicit calls to load shared libraries. In this case, the server (or other code) doesn't know about anything in the plugin until the plugin is loaded. Now a separate question may be which method should be used - modules are certainly simpler to do, but harder to control usage of that code. I guess for the object code handling, I'm more inclined to do a module type approach - that code is already compiled in, and I don't see much in the way of compelling advantage to making it an actual plugin - the code can be made a lot easier to maintain and find stuff without making it an actual plugin. That said, I can certainly see the need for plugins. It just becomes harder to figure out what approach works best for what. >> That is one consideration. Another is whether the any of the plugin logic >> itself would prevent proper re-entry (eg, static values in wrapper > functions, in >> case of python plugin, is there anything to prevent two python scripts from >> running properly at the same time, etc). > > That's tipically a problem associated with multithreading. I don't think it's > a good idea to mix the ideas of multithreaded core and the ideas of > modularized system. One big change at a time :) But it can be relevant. Imagine a case where object A is applied. plugin for A is called. As part of what A does, it applies object B. So plugin for B needs to be called. A real world case right now is things like altars that push buttons that perhaps activate something else. If the plugin code is not properly re-entrant, this fails. Right now, with the limited use of plugins, this isn't much a problem. But if a lot more stuff moves to plugins, we may run into that issue sooner and not later. The current code can of course have the same problems. query_name() has a pretty horrible hack. multithreading certainly is a different issue, but I think relative to current code, the current hacks are well known and in place to make things work. I don't really know if the plugin code will have any of the problems I mention. It it just something that should be investigated/programmed correctly so it isn't a problem. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire