[crossfire] Moving server towards a modularized system?

[tchize]

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

>  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.
-- 
--
Tchize (David Delbecq)
tchize at myrealbox.com
Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
    http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/d281da76/attachment.pgp