[crossfire] Moving server towards a modularized system?

[tchize]

Le Lundi 23 Janvier 2006 07:18, Mark Wedel a écrit :

> 
>   Well, one could change that behavior without resulting to plugins - to 
give 
> meaningful names to object types just requires an array that has the names.

I was just showing with plugins it would be easier then currently. Of course 
there are plenty of other possiblitie to solve that particular problem of 
identifying code related to a type. But plugins provides also other 
advantages: 

- third party add-ons
- easy deactivation of parts of code
- ensure there are no modules boundaries crossing (go thru a single access 
point)
- even if a non plug-in modularization is used, we would have to map it to a 
plugin system to be able to upgrade current existing plugins to it.


> 
>   And for everyone out there currently using grep - download cscope and use 
that 
> - it is a vastly superior solution (even going to plugins or whatever else, 
> cscope is a very handy tool - just run 'cscope -R' in the top level 
directory.

Am not sure it's a good idea to have de developper dependency on cscope or 
grep.

> 
>   While current code isn't particularly well organized, at the same time, it 
is 
> only in a few files, so it is not like you have to visit 30 files.
> 

It's a few file but it's spaghetti code! Not to mention the length of some 
files or even the length of some methods :)

>   True, but that goes more back to my 'poor mans version' of plugins.
> 
>   At some level, I think a poor mans version with callback registration is 
> actually more flexible.

You'd have to issue a 'patch' if you want to add third party specific features 
(like a server having it's own crossfire -> html stats system). You'd have to 
'patch' the code if you want to disable compilation of a problematic piece of 
code.

> 
> One could have a registration function like:
> 
>   set_type_callback(object_type, event_type, callback())
> 
> The advantage of registration of that form (instead of true event plugs in 
the 
> object) is that adding new event type callbacks doesn't require any change 
to 
> the objects.

What's the difference with 

 set_type_callback(object_type, event_type, somePluginMethod()) ?

the fact of adding plugin event to object instead of type, is just a 
generalization of what is currently done for existing script and is needed to 
keep backward compatibility (not to mention it also allow plugin to have some 
methods triggered only on demand).

Moreover before thinking of the specific ways to modularize things, questions 
to be answered must be
- Do we want a modularized system?
- If yes, who would lead this process, how will he lead this, and who would 
team with him.

> 
>   Another advantage is that registration above sort of provides a self 
> documentation of what function is going to be used just in that callback 
> function (and presumably, proper function naming, can be pretty clear where 
> function is located, eg apply_.. would be in apply.c, describe_.. in 
describe.c, 
> etc).
> 

I don't see how it documents itself.

>   Lastly, it could be very easy (even within the game) to disable certain 
> plugins, eg, just a call like:
> 
>   set_type_callback(.., .., NULL)
> 
>   Where with true plugins, I don't think there would be any easy way, as 
you'd 
> need to update all the objects with event_.. hooks (or keep a table 
someplace 
> saying to ignore hooks, but that would seem to get pretty messy).
> 

See my previous comment.

> 
>   That is one consideration.  Another is whether the any of the plugin logic 
> itself would prevent proper re-entry (eg, static values in wrapper 
functions, in 
> case of python plugin, is there anything to prevent two python scripts from 
> running properly at the same time, etc).

That's tipically a problem associated with multithreading. I don't think it's 
a good idea to mix the ideas of multithreaded core and the ideas of 
modularized system. One big change at a time :)


> 
>   Of course, ideally, in all cases, the answer should be no - if/when 
crossfire 
> becomes multithreaded, those things would likely need to be fixed anyways.

We are still far from multhreading. However, a modularized system would help a 
lot in future such changes.

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