[crossfire] Moving server towards a modularized system?

[David Delbecq]

Le Jeudi 19 Janvier 2006 07:44, Mark Wedel a écrit :
>   For example, there are probably about 100 different object types out 
there. 
> So if we take the module example, you either get 100 different modules for 
all 
> those objects, or a fairly big/complex module that handles those 100 
different 
> object types.

I think there are more object types than this!

> 
>   It is unclear to me right now which is the better case.
> 

none of both solutions :)

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

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)

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

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