[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re Debug messages
- Subject: Re: Re Debug messages
- From: Michael McSharry
- Date: Wed, 10 Mar 2004 08:16:00 +0000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<DIV><FONT face="Arial" size="2">Obviously
the schema architecture can exist anywhere on the continuum of free-form to
rigid. It is just a matter of design preference. I
agree with John in that some structure is
desirable.</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial" size="2">If the
design constraint is to support a central monitoring program, then it seems
that the capabilities of this program should be first defined,
then any specific schema to support it should fall
out. The proposed schema, does appear to be
more geared to a human interpretation than a target for a monitoring
program. A summary and a description would be hard to categorize
and take action automatically. Still don't know what a log file
does, but likely also needs human interaction.
</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial" size="2">When there
becomes a need to for the sending application to keyword or categorize its
data then specific schema can be defined. Until this time, my
design preference is less rigid to give the sending application the freedom
to provide whatever makes sense to it.</FONT></DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial"><FONT
size="2"><FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT face="Arial"
size="2"></FONT> </DIV>
<DIV><FONT face="Arial" size="2">
</FONT>----- Original Message ----- </DIV>
<BLOCKQUOTE>
<DIV><B>From:</B> <A
title="home-automation@xxxxxxx" href="mailto:home-automation@xxxxxxx";>John
B</A> </DIV>
<DIV><B>To:</B> <A
title="xAP_developer@xxxxxxx" href="mailto:xAP_developer@xxxxxxx";>xAP_developer@xxxxxxx</A>
</DIV>
<DIV><B>Sent:</B> Tuesday, March 09, 2004 11:03
PM</DIV>
<DIV><B>Subject:</B> Re: [xAP_developer] Re Debug
messages</DIV>
<DIV></DIV><TT>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 leve
ls, 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 variou
s 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=SlimServerReconnectionyou could
have category=SlimServer.ReconnectionI'm just
thinking that it's easier to filter by specific categories, e.g. if I want
to see all the categori
es 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</TT>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|