MS RFC 28: Redesign of LOG/DEBUG output mechanisms

[Daniel Morissette]

Frank's point about DEBUG ON not being enough to enable actual debug 
output is the only blocker in this RFC. We've had a discussion about 
this on IRC a little while ago but could not come up with a perfect 
solution, so I'll propose 2 alternatives:

1- No change, do what's currently documented in the RFC: in order to get 
some debug output you need to set MS_ERRORFILE to a valid value 
(filename, stderr, stdout or windowsdebug) * and* set DEBUG ON (or to a 
value >= 1).

Setting only MS_ERRORFILE to a valid value and DEBUG OFF (the default) 
would result in only msSetError() calls being logged which corresponds 
to the current MapServer behavior.


2- Change things so that DEBUG ON (or >= 1) automatically enables 
logging to stderr unless another output target is specified in 
MS_ERRORFILE. This has the benefit of making MS_ERRORFILE optional, but 
in order to have a way to disable logging, we need to change the debug 
levels so that:

- DEBUG OFF (the default) does nothing, not even log msSetError() calls

- DEBUG ON or 1 logs msSetError() calls only

- DEBUG 2 to 5 are various levels of msDebug() output (similar to what 
was in the RFC).


My preference is for #1 because it maintains the current MS_ERRORFILE 
behavior but I can live with both. #2 just seems less natural to me 
because DEBUG ON (level 1) only logs msSetError() and doesn't produce 
any real debug output.

Please reply with your preference if you have one and I'll update the 
RFC and call for a vote on it tomorrow.

Daniel



Daniel Morissette wrote:
> Frank Warmerdam wrote:
>>
>> I am somewhat conflicted about "DEBUG ON" not being enough to enable
>> actual debug output.  I think it is unfortunately that this and the
>> MS_ERRORFILE setting will be required.  I'd suggest that we should have
>> MS_ERRORFILE default to "stderr" which is roughly the behavior now for
>> msDebug() if built into the binaries.  But then we are likely to have a
>> lot of error noise showing up in the logs that perhaps does not belong.
>>
> 
> I see your point, but then that could also be seen as a feature: if you 
> unset MS_ERRORFILE then that disables debug output without having to 
> walk through the whole mapfile to remove all DEBUG statements.
> 
> I'm flexible as long as we can agree on something that makes sense to 
> the users and doesn't result in polluting the log files unexpectedly.
> 
> What do others think?
> 
>>
>> I would be happy to review the raster related msDebug() calls and set
>> appropriate error levels.
>>
> 
> Noted.
> 
> BTW, it could also be interesting to catch GDAL's CPLDebug calls, 
> perhaps if DEBUG >= 3 is set a the top-level in the mapfile or something 
> like that? Unfortunately we have to rely on the map-level debug level 
> for that since we cannot easily take advantage of the debug level set in 
> each of the GDAL/OGR layers to handle output from CPLDebug.
> 
> 
>> I assume that DEBUG=MSDEBUG will disappear from the version string, since
>> debugging will always be compiled in?
>>
> 
> Correct. I'll add a note about that in the RFC (backwards 
> incompatibilities).
> 
> Daniel


-- 
Daniel Morissette
http://www.mapgears.com/