Hi, > > 1. If you want to be compatible with Linux syslog, you could define the > levels the same: LOG_EMERG=0; LOG_ALERT=1; LOG_CRIT=2; LOG_ERR=3; > LOG_WARNING=4; LOG_NOTICE=5; LOG_INFO=6; LOG_DEBUG=7. That > would > make it easier if someone wanted to connect it to syslog at some point.
[[GR]] This make sense, I have updated the wiki page > 2. Additional (deeper) levels of debug information are nice because you > might include a lot of information at LOG_DEBUG level during > development but then want to turn it off when things are working, > without removing or commenting-out the statements, in case they're > needed again some day. e.g. LOG_DEBUG_2=8; LOG_DEBUG_3=9. [[GR]] Also added to the wiki > 3. There's a decision built in here: is the overall log level a > statically-defined value or a variable? [[GR]] I prefer to have the current loglevel in a variable, because it's more flexible and the runtime cost are low. > 5. It'd be nice to have a way to turn on and off timestamps on the log > messages. Either a log_with_timestamps(bool) entrypoint or perhaps > a separate LOGGER_WITH_TIMESTAMP() call? [[GR]] Yes, but this will not affect the log api in the program, but is only an additional the command line option (Added a comment on the wiki) > 6. It'd be nice to be able to tell the logging system to send its > messages to stderr, stdout, or an arbitrary fildes. Like a logging > subscription service. Then it's just a small patch to add a new > fildes and use it for a custom output-handling system. [[GR]] Yes, of course. Same as 5 > 7. A flush function is nice in case you're working with code that can > crash the system. [[GR]] Added to the wiki > 8. The idea of popping up a dialog box is tricky: > 1. Such a system should really handle localization of the messages. [[GR]] should easy solvable with gettext > 2. The dialog style may not match dialogs everywhere else on the > system. I would lean here toward an architecture where user > interaction is a pluggable module. The default version might > just interact at the stderr/stdout level. But different > vendors could plug in their own back-end for Qt, Gnome, Mac, > Windows, whatever. Such a system would also handle things like > asking for a password, verifying a certificate, etc. This is a > much bigger job than just the logging question. [[GR]] For now I would be very happy if the user get an error message if something goes wrong (which is not only send to stdout = goes to nowhere). You are right, but this does not affect the logging api, so it can be implemented in a second step. > 3. So... I'd just kick that can down the road for now. If it's > easy to output the information to a file, people can write their > own code to deal with that file. For now. > [[GR]] My problem is not logging, but error handling. I already took me hours of debugging my system, until I realyized that error message (if any at all) goes to stdout and will not show up at all if I start freerdp as a gui program. They do not even go to stderr, so there is no chance to distinguish between normal output and errors. If freerdp fail it return with exit code 0. From my point of view having an error handing/reporting is so important, that should have been implemented before 1.0. That's the reason why I made a suggestion and volunteer to make a first basic implementation, which at least defines and implements the API which should be used to send log/debug/error messages. How these messages are shown to user can be easily improved at any time, without problem, but the API needs to be well defined. Regards Gerald > Regards, > Daryl Poe > HP Thin Clients > > On 12/5/2012 12:17 PM, Marc-André Moreau wrote: > > <clip> > > As for using the mailing list, yes, it ought to be used. Another > > discussion for which I would really appreciate some help is the design > > of a better debug/log system. The current one is severely limited, and > > there is a large number of requirements which an ideal debug/log system > would need to meet. > > Since this affects everyone and pretty much all the code, I need your > > input on this. We're currently collecting information on this wiki page: > > https://github.com/FreeRDP/FreeRDP/wiki/Debug-System > > > > I repeat, I need input on this. I'd rather have it before than after > > it's changed. It's a tough design question, and I'd rather make the > > change to a well designed debug system once than switch to something > > partially proper and still need to change it a lot later on. > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Freerdp-devel mailing list > Freerdp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freerdp-devel ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
