Re: libgnustep-base split proposal

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> 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:
> >
> > > [snip]
>
> 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.

I think its actually much easier to classify than you thing. The audience to 
consider is "run-of-the-mill" user running a packaged installation. After all, 
this is the target audience in the end for just about everyone.

In my experience, most such end users only want logs containing bad things they 
really need to know about. Less, rather than more.

Power users and developers have the savvy to up their logging level. They can 
also be presumed to understand more detail/technical info.

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

Basically what I'm getting at. Problem is, at the moment there isn't any rule 
or guideline about how to classify such messages.

The problem we have with NSWarnLog() is that it is being used for information 
level messages rather than warning/alert level messages. It should be more like 
GSInfoLog() to be clear. I'd expect most packaged installs to have such 
messages off.

In my view there are lots of messages which need to be sorted. I would rather 
change them after we have some general agreement on categorisation.

> 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.

Great. With you on that.


Regards,
Sheldon