[crossfire] code cleanup commit.

[Tchize]

In fact, That's somehow a bad idea to want some kind of multicategories 
logs.
At the moment you write you code and decide to put some logging inside 
it, you must know exactly where this log call belongs to.

Let's assume you know a specific log message X at a specific place in 
code belongs to 'map handling and monster handling', you write your log 
call with categories  'map & monster'.
6 month later, someone decide we need an additional category for 
everything related to Traps, perhaps because we have lots of traps issue 
(just an example). You have to go thru all the code, analyse all the log 
calls and for each of them decide if you want to add the Traps category. 
Nobody will do it, and it will end up in a state where not all logs call 
that should go in a specfic category are in it.
Moreover, everytime someone will want to write a log call , he will have 
to scrap his head to list the categories it should fit in. At that time 
there are 2 possibilities
- either he does it fast and quickly decide what categories it is in -> 
you end up with hih risk to forget some of them
- either he does it the slow way an check everyt category to see if it 
fits in -> you end up with a bored coder and a risk for a log call to be 
in too much categorie

Last but not least, with a categories system, you still have the risk to 
be over informed when you enable the category, so much log call will be 
enabled when you enable a category you risk to have so much information 
that you can't find what you need inside.

On the other hand, if you assume a log hierarchy, like this one

crossfire.objects.monster.movement
crossfire.objects.player.movement
crossfire.map.load

you can

* enable everything related to object manipulation as a whole
* enable everything related to monster handling
* enable everything related to maps
* enable everything related to crossfire :p

Last but not least, i point you to this:
http://log4c.sourceforge.net/
according to their mailing list there has been success in compiling for 
windows too, it might be worth an attempt by a window guy and a linux 
guy to see if we can use this a crossfplatform way (either as a lib, 
either incode).
On last ressort we probably can also try to map log4cpp

Mark Wedel wrote:
> Tchize wrote:
>   
>> Sorry, jumping in Thread a bit late.
>>
>> I have quite a few experience with logging mecanism, here is my suggestion
>>
>> Arrange log entries in a hierarchy (scopes) like is done in java logging 
>> mecanisms:
>>
>> example:
>> common.object (for everything related to object)
>>
>> Provide different levels of logging
>> (idea: finest, fine, info, warning, error, critical), default visible 
>> level would be info
>>
>> Then you can say in config (or command line)
>> default=warning
>> common.object=finest
>> server.monster=finest
>> server=info
>> random_maps=info
>> socket=info
>>
>>
>> Provide with the possibility to check if a specific level is enabled
>> if (loglevel_enabled(scope,LOG_FINEST)){
>>    /* do very complex operations here that can not be easily resumed in 
>> a function call */
>>    /* optionally at end issue a log call */
>>     LOG(scope,LOG_FINEST,result_of_complex_logging_operations)
>> }
>>
>> Use also as information the line,file,function information, as 
>> preprocessor provide them , but do not use them for filtering, use them 
>> only when analysing a log to know where a problem occurs
>>     
>
>   That all looks good.  But one question this - is it possible for a single log 
> method to belong to several categories?
>
>   I can see lots of things within the game where it is a question of 'is this a 
> map related log message?  object?  monster?'  Since they all interact, it 
> becomes tricky.
>
>   I suppose this could perhaps get sorted out by clearly defining what 
> categories something should be logged based on the operation in question.
>
>   And I agree that log statements should generally always be enabled.  But often 
> times, if you look at the log messages, the detail is just way too much to 
> enable them all, even within a category, unless subcategories are defined or 
> there are lots of category.
>
>   A case I can think of here is the socket stuff.  I could see that if I'm 
> writing a new socket command, I may want to have lots of logging info (at most 
> detailed level) on what is going on.  But I don't want that high level of 
> logging for the rest of the socket code (item, map, whatever else) as it then 
> likely makes it too hard for me to find my own log information (oftentimes, you 
> want to see those log messages as the program is running, not to look over the 
> logs after the run).
>
>   So I'm not sure how to best handle that.
>
>   I do agree that if there are portable logging solutions already out there, 
> that it makes sense to use them vs writing out own.
>
>
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>