[crossfire] Moving server towards a modularized system?

[Yann Chachkoff]

Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit :
> Frankly, I have to agree with mikee to some degree on this point. I
> generally have little trouble finding something after a combination of
> getting a feel for the code, which I have gotten pretty good for a while
> now, as well as skilled grepping.
>
"Finding something" is not really that difficult. However, adding new things 
often is, because it is not uncommon to have to modify the code at several 
different places. I see this as inherently bad - if I want to implement a new 
object type for example, I'd prefer putting its whole code in a single place 
than having to edit several source files (some being in common/, others being 
in server/). 

Of course, a skilled coder that has got a good knowledge of the Crossfire code 
generally has little difficulty to find its way through the code - but not 
every contributor can/wants to afford the time required to get that in-depth 
knowledge of the code; besides that, having to play with grep to find the 
relevant piece of code is already a failure in itself, IMHO: if even somebody 
used to the source has to rely on a search engine to find its way through it, 
can we consider there is no problem ?

> However aside from some things like this, I do find modularization can
> have merits, it just depends on 1) How much effort it takes to
> modularize, 
>
It actually depends on the level of control you want to grant to the plugins. 
The most extreme case would be to export all the functions currently in the 
code - to do that, you'll have to provide a wrapper for each function you 
want to export. That's a lot of functions, but let's not forget that a 
significant part of those are only used by specific pieces of the code, so 
the actual useful number is definitely lower than that by a significant 
margin.
As for the code located in the module itself, there would be little to change; 
at most, the function names being called (to call the wrappers instead), and 
the initialization/termination code (which will quite probably be the same in 
most cases).

> 2) How effective the modularization API is designed (i.e. 
> currently the existing plugin API is vastly insufficient for server
> modularization) 
>
I think it is unsufficient for two reasons:
(a) The API provided to plugins is not complete enough;
(b) There are no ways for a plugin to interact with the server outside of the 
local/global events.

I think (a) can be completed as modularization advances - if I tried to make a 
plugin out of alchemy, I'd check all the "external dependencies", then move 
them into the plugin API if required. It however means that the API will be 
an evolving target as long as modularization is in its early stages, though. 
As for (b), as I said earlier, I think it can be solved by offering to 
plugins the possibility to hook themselves to some often used functions in 
the code. In such a case, I think the plugin code should get hooked by 
callbacks contained in objects whenever possible (so, instead of calling 
apply(op) and make a switch(op->type) in apply, the specific behavior of op 
would be directly bound into the object as a callback and called by 
op->apply(op)). In that scenario, there would be no overhead involved when 
compared to the current situation - it would basically replace a switch 
statement by a function call.

> and 3) Where we draw the line of what to modularize. 
>
I'm not sure a line has to be drawn to what/what not modularize. I think a 
more important question is: to what level should the modularization take 
place ? I don't think there are simple answer to those questions. I'm not 
even sure answering them in a definitive, strict way is really required.

> Personally, I don't think we should modularize very much, but if the API
> is good enough (which I would likely be picky about myself), then it
> might be worth doing for a limited number of things.
>

> Indeed. On this example, IMHO random maps are not optional, as they are
> essential to some quests, and also soon would be used by land plots  
> (though land plots would in my opinion be a relatively good thing to  
> implement as an optional-but-defaultly-on C plugin) 
>
Note that "optional/necessary for some quests" should not be a critera for 
modularization IMHO, because it is one you can use to justify nearly every 
function implemented in the game.

On the other hand, the "optional/necessary for the server to run" sounds much 
more relevant. Can the server work without random maps ? Of course - it 
simply means that the maps using that feature will not work, but the others 
will be completely unaffected. It has no impact on the gaming rules, and no 
influence on the characters. 

> Personally, I think that a C plugin interface for modularization, it 
> should provide full direct access to the data, though recommend use of  
> wrappers functions unless you know it's safe. 
>
Nothing currently prevents a plugin to modify the data it has access to 
directly - but of course, that's unsafe access, so if the plugin makes a bad 
modification to the data, or forgets to notify the server of it if necessary, 
then it will probably crash the server. Accessing data directly or through 
wrappers is basically a tradeoff between performances and security. 

In the case of modularization of the existing code, I'd say that direct access 
wherever possible should be kept - accessors for such data modifications 
would probably be used only for debugging purposes (as a wrapper can check if 
the data modification is "legal" or not, and thus can help detecting a whole 
range of errors). 

-- 
Yann Chachkoff
-----------------------
Garden Dwarf's Best Friend
-----------------------
GPG Key    : http://keyserver.veridis.com:11371/export?id=9080288987474372064
Fingerprint: 6616 2E02 BAD2 4AEF C90A  F1EB 7E03 AAB9 844D 25E0
-------------- 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/20060117/b55430ba/attachment.pgp