Re: libgnustep-base split proposal

[Richard Frith-Macdonald]

On 25 Feb 2006, at 04:37, Sheldon Gill wrote:

> Richard Frith-Macdonald wrote:
> > On 23 Feb 2006, at 01:04, Gregory John Casamento wrote:
>
> > Actually ... I'm getting the impression that the best thing to do  
> > might just be not warn about missing external resources if the  
> > library is installed in a path other than System/Library/Libraries
>
> Might I suggest:
>
> library messages (base & gui) are assigned a level:
>
>   Debug
>   Technical
>   Informational
>   Warning
>   Error
>   Critical
>
> and output is according to chosen level.
>
> If the library is looking for a resource and can't find it
>   If the problem means execution can't continue
>     report as Error
>   If the problem is likely to cause execution failure
>     report as Warning
>   Otherwise
>     report as Technical
>
> {Exact details, of course, to be agreed...}

Well, I think we already do that ....

A real error which means that execution can't continue ... should  
raise an exception and get logged that way.
A severe warning (one notch down from fatal) should get logged with a  
simple NSLog() ... it shoulod always be seen.
We have NSWarnLog() and friends for information/warning level of  
logging ... things we expect people normally want to see, but which  
can be turned off with a runtime option.
We have NSDebugLog() and friends for technical/debug  level of  
logging ... normally off, but we can turn them on with a runtime option.

So, only four categories rather than six ... even so, I think  
NSWarnLog() is hardly ever used ... I think it's really,  really hard  
to assign some messages to particular categories ... for anything  
which is not a fatal error and is not clearly for  debugging  
purposes, it's horribly different to classify, because what is  
appropriate usually depends on the audiance/user and what they are  
trying to do with the library.

However, an audit would be good ... I suspect a number of NSLog()  
calls should be NSWarnLog() or even NSDebugLog()

What I was referring to in an earlier email is the idea that in some  
circumstances (a normal install) missing resource files are a real  
oddity and mean that the program won't behave as expected ... which  
may well constitute a failure, but in other circumstances  
(deliberately installed without resources as a standalone library)  
you could assume that the lack of locatable resources was  
intentional, so any program using the library presumably expects the  
changed behavior and it is not a failure.  Thinking more about it,  
this is probably not a good idea to infer from library location.