[crossfire] Moving server towards a modularized system?

[David Delbecq]

Le Mardi 17 Janvier 2006 08:00, Mark Wedel a écrit :
> 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

Nothing would prevent all those 'basic plugins' to be gathered together. 
eg all kind of current exit in a module along with walls, grounds, name this 
module 'basicLayout'
anotherone for movment stuffs
another module regrouping monster stuffs
anotherone for all kind of traps 
...

Common lifecycle is 'add new feature in existing code, when it becomes lots of 
line, move it to it's own module', unless of course you know from the start 
it will contain lots of code ;)


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

principles of methods polymorphism in object oriented programming ;)

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

Well you put the finger on it. Adding a new object is generally adding a 2 
lines code to apply which calls myObjectType_apply(). and same to describe, 
sometimes, also for some same to move_object(). Damn this looks to me like 
the pattern of registering listeners to some events :D

> 
> 
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> 
> 

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Pingouins dans les champs, hiver méchant