Hi, Since there are many features which we want and eventually will want, we should design the basic API to be as extensible as possible. This means we can put some reserved fields, flags, etc, which will allow us to add functionality later on without having to break a lot of code.
The most basic thing that we want from this debug system is the possibility to redirect the output where we want. I think that we might need more than just macros to get all that we need, even if for the most basic functionality I'm pretty sure we can figure out a way. One example that we may look at is the android native logging system: http://mobilepearls.com/labs/native-android-api/include/android/log.h Very simple, and it looks like the current proposed API, except that it is not done using macros. In fact, the android build system adds a single .c file to the list of files to be built, in order to avoid linking to a shared library. We don't need to do that, we can simply leave it in the utils and link to it. The logging system must be: easily configurable (we might even think of adding configurable options in the registry) output must be customizable (separate the textual content from the timestamp, line number, function name, etc, and have the output format customized) There should be a cross-platform printf for formatted textual content (especially for 64-bit values and such that have less portable format strings in printf) There should also be something for hexdumps and images, or anything which is non-textual content. Oftentimes we want to capture both, but the hexdumps really just make it really hard to read. If we could filter by channel when reading the logs, it'd be awesome. *filtering!* filtering would really be important! it's really hard to read the logs when there is just so much information, so I end up reducing the amount of debug info to visualize certain parts but then I need more details, etc. Unicode support. Right now we're "printing" unicode strings with the hexdump function. That's just a start On Thu, Dec 6, 2012 at 3:55 PM, <rich...@ecos.de> wrote: > > > I did a look in the proposed API and it is simple... > > > Personally I think we need to have something like an exception system (you > can take a look as GNU Parted does it) so we can even make special handlers > in GUI applications and have it handled in different ways. > > > We can offer an default exception handler that could work mostly as you > designed. The log part of it, could be done exactly as you designed but > error hangling is not flexible enough. > > > [[GR]] I also like the idea of using exceptions for error handling, but I > think this behind the scope of the logging API and a much bigger change. So > for now I would like to stick with a simple logging/debug/error reporting > API. > > > Gerald > > > > ------------------------------------------------------------------------------ > 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
