Logging should be as easy as writing a comment! It should not require the developer to interogate variables and objects and manually convert them into strings. Worse, that manual conversion code tends to get duplicated -- its usually too small and too specific to be encapsulated in helper methods. Logahawk uses Formatters to avoid this unnecessary tedium.

Logs should provided lots of information and be easy for developers andoperators to read. It is my opinion that logs can be a window to a program's soul. They can be a system's heartbeat monitor, an application's autobiography, and a program's status report all in one. Note I say "can be" -- logging is often too awkward to let developers naturally achieve this value. Logahawk's primary goal is to make logging easy; if Logahawk succeeds then the information in the log will be more useful.

Logahawk is designed to support domain specific logging. A general purpose log will only provide general purpose information, and can be analyzed only be general purpose tools. Every serious application either works within a domains or creates a new domain, and that domain has its own vocabulary and lingo. The intent of Logahawk's Formatters is to allow developers to create logs that best support that domain.

Logahawk is designed as a wrapper or an adapter to your existing logging infrastructure. Logahawk's design is agnostic to any particular logging framework. How you decide to integrate Logahawk with your application is completely up to you. See Integration for details.

Every significant construct in Logahawk is defined by an interface, not an abstract base class. Developers should have the freedom to replace anything and everything, however they see fit. Many logging frameworks make it difficult to extend or outright replace their core classes. Some of the improvements planned for Logahawk are to provide more or simpler interfaces for core classes.

Hand-in-hand with the difficulty of extending many logging framework's core classes, many logging frameworks provide (and some even require) a single configuration mechanism, usually configuration files (or databases or whatever). Very few, if any, make configuring logs at compile-time or dynamically at run-time easy. Logahawk leaves configuration up to the developer, allowing the developer to provide only what they need, or deferring configuration responsibilities to the underlying framework if that is sufficient. (Logahawk was actually designed for a system that needs the ability to dynamic create new log files at runtime, and where a user-editable configuration file and user-readable logs are a security risk.)