[crossfire] Moving server towards a modularized system?

[Mark Wedel]

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.