On Thu 22/05/14,09:34, Michael Whapples wrote: > PS. The default is actually to write to STDERR. I guess since these are libraries and not end user applications, the default should be to file. An end user application can override this given the right options as previously discussed. I am in favour of locality by default, making it hopefully easier to track and trace bugs through various layers of the system, rather than one massive stream/file with all debug information from all subcomponents, reasoning as follows: I am thinking that on the liblouisutdml, nvda/orca level you log your own tracing information and the information that you send/receive from liblouis. If input/output for a particular call (usually consecutive lines at the level of utdml/nvda/orca) is thought to be wrong, then we should be able to open the liblouis log and trace the particular call. The consecutive input/output lines at your level should be enough data to make a liblouis test case/bugreport. The same for brailleblaster, the logging at the application level should be input/output interactions with the liblouisutdml library. When an end user finds an error, they open up the brailleblaster log and can locate the segment that is being sent to liblouisutdml which produces unwanted behaviour. This input/output can then be dumped into a liblouisutdml testcase. I guess what I am attempting to express is slightly different requirements for another sinario where logging needs to be useful and effective. 1. How to signal to the user that an error has occured and at what component it happend. 2. How to make it easy for us as developers or interested log readers to quickly identify the reasons of a particular problem. thanks, Mesar
Attachment:
signature.asc
Description: Digital signature
