Sanjay,
Please see responses inline:
On 03/17/10 04:35 PM, sanjay nadkarni (Laptop) wrote:
> william,
> Comments in line.
> On 03/17/10 03:20 AM, William Schumann wrote:
>> Virginia,
>> Please see replies inline:
>> On 03/16/10 09:50 PM, Virginia Wray wrote:
>>>
>>> On 03/16/10 11:09, William Schumann wrote:
>>>>
>>>> RE: 6. Output Format: There should be sufficient parseable data or
>>>> metadata in the log messages so that they can be predictably and
>>>> easily filtered. For example:
>>>>
>>>> <timestamp>;<severity>;<application id>;<specific ID>;<content
>>>> type>;<payload>
>>>>
>>>> - where "specific ID" is a number that is cataloged (for ez lookup,
>>>> localization, etc.)
>>> What kind of specific id are you referring to? A process id? I'm
>>> not sure what you're referring to here or how it would be generated.
>> A specific ID would be a number or name that identifies an event.
>> The event could be a milestone ("install complete") or an error code
>> ("disk full", "assertion failed"), for example. It would be unique
>> in itself or in combination with the application ID. The idea is to
>> standardize the way it is referred to so that it can be filtered by
>> ID later without having to search for text that can change at any time.
> I believe what you are expressing via specific ID is the error message
> type information which will be available. The error handling
> framework provides specific ids and associates the messages with
> them. There is also an ID associated with the component which
> generates a message by default. So if one wanted to filter for
> debugging purposes on that component it is possible.
OK. I think that this should be added to the document.
>>
>> The codes would not have to be generated. Codes to represent events
>> that occur at any time, such as "disk full" could be taken from a
>> standard library. Application-specific codes could be defined
>> locally to an application, module, or class, e.g.,
>> TargetDiscovery,slice_not_found. In a program, there would be a
>> symbolic reference to the code. Perhaps the codes could all map to
>> exceptions. Having them cataloged would be nice, but the main idea
>> is that the codes themselves be reliable whereas the text is subject
>> to change and localization.
>>
>>>
>>>> - "content type" in the sense of an SMTP email message
>>> The output format shown is specific to output to a File. There are
>>> different types of handlers that are available through the Python
>>> Logging
>>> module that we can engage for different types of format. For
>>> example, there is an SMTP handler that would manage output to an
>>> SMTP mail server.
>> What I am proposing here is embedding the content type into the
>> message, i.e., the input. That would permit more sophisticated
>> payloads that were customized for a particular output content type:
>> *HTML*, for example. You could even have crazy stuff like graphical
>> screenshots in the log for the GUI installer.
> Indeed these are some of the potential capabilities we discussed. The
> payload is planned per handler not per message. It is worth thinking
> what this might mean.
The call to log the message in the document does not specify either a
handler or a content type. Quoting:
>
> InstallLogger:log_message(ID, Level, Message)
>
If alternative content types are to be used, it seems that the way to
specify them should appear in the design document. What is "Message",
really?
There could be a lot of crossing over between content types. For
example, HTML tags are useless in an ASCII log file; however you don't
want to ignore the content type entirely, but rather, either strip the
HTML tags or use a smart interpreter to make the ASCII output
approximate the HTML output. A handler for content type=HTML might not
be able to display a screenshot, but it might output a clickable browser
link to a screenshot (and an ASCII file log could list a file name of
the image).
Suggestion: mention in the document a raw handler that files all log
information for later analysis regardless of content.
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20100319/72792bd9/attachment.html>
