Kato Design Benefits

The Kato design has the following benefits:

  • The Kato client is built as a .dll file that can be linked into any application.
  • The Kato logging interface is implemented primarily as a C++ class. An application can easily pass logging objects when the logging interface is implemented as a C++ class. A flat C interface is also exposed. This is useful if you want to dynamically load Kato.dll at run time, or if you prefer using C.
  • You can create more than one Kato object within any application. Each Kato object maintains a unique stream to the CETK server. This design may be useful if you have multiple threads performing independent tasks. Each thread can log independently of the other thread and generate separate output.
  • The Kato interface supports ANSI and UNICODE logging.
  • The client side of Kato is small and fixed in size. The size does not dynamically change if logging output systems are added or deleted because the logging output systems reside on the server side.
  • With the client/server architecture of Kato, applications and the CETK server can run on separate machines running different OSs. The Kato client currently runs on any Windows–based desktop OS and on Microsoft Windows CE.
  • Kato supports hierarchical logging. Applications may begin and end levels at any time. This design is useful for group logging or to show a log that is a subset of the current log.
  • Kato supports log filtering. Each log line is associated with a verbosity value. This value determines the importance of a given log line. You can set a filter for each output system using the CETK server. You can use this filtering mechanism to mask out a log of less importance.
  • Kato supports verbosity tracking. The Kato client keeps tallies for each of the different verbosity values. These values can later be queried to find out how many lines of a given verbosity have been logged. This is useful for generating log summaries and pass or fail information.
  • Several callback hooks have been placed in the Kato client. Applications can request to have the log of all Kato objects within the given process routed to a callback. This design can be useful for test harnesses that request to perform a task with the log.
  • Third-party add-on systems can easily be written and plugged into the server. These systems can monitor data or store data to any device they choose. You need not be concerned with multi-thread issues and synchronization for your system because the server internally prohibits reentrance to the systems.
  • All user interface (UI) and configuration has been isolated to the server side.
  • The server UI is object-oriented through a drag and drop interface. Logging streams from Kato clients have a many-to-many association with output systems. More than one output system may be attached to a single Kato client log stream. Likewise, multiple Kato client log streams may be attached to a single output system.

See Also

Kato Logging Engine

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.