[crossfire] Moving server towards a modularized system?

[Mark Wedel]

David Delbecq wrote:

>>   This gets especially messy if say 10 object types are complex enough that 
> they 
>> really should be in their own module.  So now you have those 10 separate 
> modules 
>> + common module for other 90 types.  This then starts to get away from 
> making 
>> things easy to find (is it in the common module, or one of those other 10)
>>
> 
> Let's say i've got a problem with a buggy trap. This is how i see it:
> 1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me 
> type xyz (the trape type) and maybe also in the dump the is a list of plugins 
> linked to this object.
> 2) i go in the code of this (or those) module and start trying to fix the 
> bug :)
> 
> (please note, currently to fix an object, the procedure is something like dm 
> -> get type -> open define.h -> get the associated #TYPE for this type -> 
> issue a grep on this type to find where there is specific code.)

  Well, one could change that behavior without resulting to plugins - to give 
meaningful names to object types just requires an array that has the names.

  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.

> 
> Also, having a simple document of which module does what would be 
> interresting. It's easy to manage (a module X -> description chapter and a 
> item type -> module chapter)

  But that sort of sidesteps the point, doesn't it?  Isn't one of the issues 
right now that code is hard to find?  If we have to document the new code, that 
doesn't seem to be going in the right direction - for that matter, a document 
could be written right now of 'these are steps to do to make a new object'.

  While current code isn't particularly well organized, at the same time, it is 
only in a few files, so it is not like you have to visit 30 files.

> 
>>   True.  However, I'd think that to do this by true plugins, the 
>> objects/archetypes have to get updated, eg, hooks added for describe item, 
> apply 
>> item, etc.  My poor mans version avoids that.
> 
> Or we can have a plugin, in initialisation code do a 'plug those callbacks to 
> type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you 
> omit the 'traps' plugin from server code, you can have a server which knows 
> nothing about traps :p (an we could imagine the traps module handling trap 
> objects and trap related skills :p). If you omit the all spells modules, you 
> could have a server in which casting spells is impossible (only bash and 
> crash)

  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.

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.

  Another advantage is that registration above sort of provides a self 
documentation of what function is going to be used just in that callback 
function (and presumably, proper function naming, can be pretty clear where 
function is located, eg apply_.. would be in apply.c, describe_.. in describe.c, 
etc).

  Lastly, it could be very easy (even within the game) to disable certain 
plugins, eg, just a call like:

  set_type_callback(.., .., NULL)

  Where with true plugins, I don't think there would be any easy way, as you'd 
need to update all the objects with event_.. hooks (or keep a table someplace 
saying to ignore hooks, but that would seem to get pretty messy).



> 
>>   Another question is whether a plugin can call another plugin - that in 
> itself 
>> could perhaps limit the ability of some things to be in plugins.
> 
> Very good point.
> Plugins put aside for a few seconds, in modular project, there is usually a 
> notion of modules dependencies (module X depends on module Y and core, module 
> Y depends on core). I think we need to handle this dependencies system or we 
> lose a bit part of interest in modularization. Back to plugins, that means we 
> need plugin X to be able to do calls on plugin X. This shouldn't be difficult 
> to do. Simply a plugin would link a list of callback in initialization but 
> would also provide core a list of 'public callback' (that is a list a named 
> method). Core will the provide every plugin depending on X the possibility to 
> access them.

  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).

  Of course, ideally, in all cases, the answer should be no - if/when crossfire 
becomes multithreaded, those things would likely need to be fixed anyways.