[crossfire] Moving server towards a modularized system?

[Mark Wedel]

Yann Chachkoff wrote:

> 
> Well, it really depends on what the C code requires as dependencies - the
> Python plugin has one with the python libs for example. But stuff that was
> initially in the server code would have no such external dependencies indeed.

  True.  I imagine dependencies to be fairly standard C dependencies.  But I 
could imagine someone writing a plugin in C++ with appropriate wrappers.

> 
> On the other hand, I think splitting the code in "logical entities", more or
> less independent of the others, would be a path of thinking to try. As such,
> random maps would appear as a good target for modularization, since it
> doesn't really depend on anything else, apart from very basical operations,
> and is called only at a few places. Alchemy would be another good candidate -
> both are very important in the game, yet are working very much like "black
> boxes" - complex code with relatively limited interactions with the rest of
> the code.

  Agree.  And in fact, any object that does something 'interesting' when applied 
could be a plugin, since most such objects are also very well self contained.

  However, I'd counter that if it is just 20 lines of C code to do that 
'whatever', it could be more convenient to just add that 20 lines to apply.c

  I say this because I imagine plugins would probably be organized by 
plugin/C/<plugin_name>.   Maybe have one directory for basic plugins (one in 
which the entier plugin is in one file).  But if plugin grows to the extent that 
there are 50 'trivial' plugins, one could say finding the code there isn't any 
more convenient than having it sit in apply.c

> 
>> I'd think that if there is a C plugin, aside from the different passing in
>> of the values, and using appropriate callbacks for functions instead of
>> calling
> them directly, it could access the function data directly? Eg, it should need
> to do a plugin callback to set the dam of an object, it could just set
> ob->dam?
> 
> Theorically, yes: there's nothing preventing such a thing. Wrapping such
> access behind functions was basically to allow checking that the values
> passed were in the correct range, and to provide encapsulation of the data
> (so that a plugin wouldn't get tempted to directly change fields it wasn't
> supposed to change without a high risk)

  I'd imagine it is more important for the plugin wrapper to provide a 
consistent interface to the various functions, so that if a function handling 
changes in the C code (say a function now takes another argument), that all the 
plugins don't have to be rewritten - they can keep using the existing code, with 
the wrapper just passing in some default value.

> 
> Sure ! But I think such changes would be easier to make if the code was, in a
> way or another, "split" into smaller entities, so that they affect only a
> limited part of it. And indeed, a lot of functions would benefit from some
> in-depth rebuilding. Also, part of the problems of code debugging/maintenance
> come to how things are distributed all around the code - finding where to
> add/change things is a rather complex task. Making small changes to make the
> code more "readable" and "editable" would thus be another important point to
> achieve, IMHO.

  True - some functions have grown a bit in complexity and could certainly use a 
rewrite.  And I could envision doing some things as plugins would make some 
things easier/more modular (Going back to what someone said, objects that the 
player uses are complicated - need to update the apply code, but depending on 
the object, may also need to update the code that actually describes the item - 
I could see with appropriate plugin support, all that could be done in the 
plugin, so all code related to that object is in one place)