MS RFC 28: Redesign of LOG/DEBUG output mechanisms

[Ed McNierney]

Folks -

It would be helpful if it were possible to turn DEBUG ON right from the
start, so debug/log messages could be generated during the loading and
parsing of the map file.

Quite a while ago I spent some time trying to optimize my configuration, and
couldn't quite reconcile what seemed to be fairly rapid layer rendering with
rather slow map output.  I then realized that I was using overly-complex map
files and 2/3rds of my overall run time was being consumed by loading and
parsing the map file so I could turn DEBUG ON.

I suspect there are others who could benefit from logging during map file
loading, so it would be helpful to enable this right from the start.  I am a
little reluctant to suggest that the presence of the MS_ERRORFILE variable
should trigger it, as I suspect users might find that a little awkward and
leave it on when they don't intend it.

     - Ed


> From: Frank Warmerdam <warmerdam at POBOX.COM>
> Reply-To: Frank Warmerdam <warmerdam at POBOX.COM>
> Date: Fri, 15 Jun 2007 15:41:12 -0400
> To: <MAPSERVER-DEV at LISTS.UMN.EDU>
> Subject: Re: [UMN_MAPSERVER-DEV] MS RFC 28: Redesign of LOG/DEBUG output
> mechanisms
> 
> Daniel Morissette wrote:
>> Hi Dev's,
>> 
>> I have prepared a first version of MS RFC 28 that proposes a cleanup of
>> the LOG/DEBUG output mechanisms while keeping things simple (I like
>> simple) and not breaking too much existing code:
>>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-28
>> 
>> Comments welcome... and expect two more RFCs from me today...
> 
> Daniel,
> 
> I like it.
> 
> 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.
> 
> Keeping the error file handle in the error context should address
> multithreading just fine as I believe you and Tamas have already
> concluded.
> 
> I like Tamas' idea of an MS_ERROFILE windowsdebug option on windows.
> 
> Potentially we could offer a syslog option on unix that is roughly
> analygous though I don't feel any compelling need for this.
> 
> I would be happy to review the raster related msDebug() calls and set
> appropriate error levels.
> 
> I assume that DEBUG=MSDEBUG will disappear from the version string, since
> debugging will always be compiled in?
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http://osgeo.org