Re: Re Debug messages

[John B]

Hi Michael,

> I generally believe that the log and error schema should be relatively
free-form. The definition of buckets for types of messages presupposes an
eventual use for this information, however this use has not been defined so
there is no good basis for any type of categorization. That is why in the
Writelog application the "type" field is free-form. This allows
any application
to send what it feels has some significance for logging and debugging. An
application that is later developed to manage errors, debug, or other log
information will be developed based upon the context of the data that is
being
managed. Future applications will likely have square pegs and the
definition of
round holes for these pegs will result in a constrained implementation.
> For any given application a convention can be established such that
the
content of the "type" field can specify debug at various
criticalilty levels, or
that resources are low, or interface power is off, or whatever is
appropriate
for that application.


The issue I see here is that you don't want each application doing it's own
thing, to such an extent that the central monitoring program needs to know
the
details of every application it is monitoring.

Therefore I think you need to define at least some fixed elements of the
schema
so the management application can filter, for example, on errors vs.
informational messages, without needing to know the specifics of any
application.

Stuart,

> >Class = xAP.Debug
> >
> >debug
> >{
> >severity={info, warning, critical, fatal}
> >description={summary}
> >detail={longer detail message}
> >logfile=
> >path=
> >}

I'd suggest specifying some guidelines as to when the various severity
levels
are to be used.
Otherwise different developers may interpret them differently.

> 1. Drop path and combine it into a single entry, logfile? True, this
> is a file relative to the source of the message and won't always be
> applicable e.g. to devices without any storage capabilities. Or it
> could use a UNC pathname.

As Michael says, is this really of any real-world use?
I guess if the log file contained other information relating to the
particular
debug message then it could be useful.

>
> 2. Added Category, a string field that can be used to group debug
> messages together.

Why not make this hierarchical, e.g. instead of
category=SlimServerReconnection
you could have
category=SlimServer.Reconnection

I'm just thinking that it's easier to filter by specific categories, e.g.
if I
want to see all the categories relating to SlimServer.

> 3. Perhaps move the log file items to a separate block as this means
> multiple debug messages can be transmitted in the one block, but all
> logged to the same file? Or maybe they go to separate files so that
> isn't appropriate? Perhaps an overriding log file block e.g.
>
> Debug.Log
> {
> File=<path to log file on device>
> }
>
> This applies to the entire message unless the individual item
> specifies a separate entry.
>
> Way more complicated than is perhaps required.

I'd agree - I think keeping the logfile element to each block would be
sufficient.

Regards,

John