[crossfire] Moving server towards a modularized system?

[Mark Wedel]

tchize wrote:
> Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
> 
>>  However, I think if you start grouping all that stuff together, you start
>> loosing some of the advantages.
>>
> 
> Depends once again on the size of things you regroup and how much they have in 
> common. if you start making 80 modules for what is current server i think you 
> also miss the point on managability :)

  Right, but you have to keep this in mind.

  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.

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

  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)


> 
>>  But one could do that to some extent without plugins.
>>
>>  You could for example set up something like:
>>
>> struct object_type_description {
>> 	functype	apply_func;
>> 	functype	describe_func;
>> 	functype	....
>> } object_actions[MAX_OBJECT_TYPE
>>
>>  Then in the code, you could do things like:
>>
>>  if (object_actions[op->type].apply_func)
>> 	object_actions[op->type].apply_func(...)
>>
>>  In a sense, a poor mans/specialized plugin.   You then just need one
>> initialization function, but all the specialized code related to object type
>> itself could be in one place.
>>
>>
> You said it, it's the poor man version ;)
> If we modularize things, it is a good thing to have a plugin part in it. Even 
> if some of things currently in core could be done as module not plugins (like 
> let's say, binding a libCrossfireRandomMap.a at link time) you will probably 
> get into the case when someone want to add new behaviours in plugins.

  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.

  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.