acme was asking about best practice for logging modules, citing Log::Log4Perl and Log::Dispatch. By preference and experience i'm a unix programmer, but recently (last couple of years) i've needed to write some stuff for the win32 platform. One of the more difficult things i've encountered is trying to log 'natively' on win32 and unix.
For me, native logging on win32 means logging to the windows event logger, which, as seen at Win32::EventLog, requires a numeric EventId and a set of parameters joined by the NUL character. Win32 combines these with a DLL provided by the application writer to produce the final localised message seen by the user in the event viewer. Unix on the other hand via syslog, requires a string which is sent to the appropriate log file. This presents a big problem when trying to create a common logging API.
So far, the usual way of combining the two seems to be by in the background, providing an EventId of 0 (or whatever number) and a single parameter consisting of the entire message. This allows this sort of interface:
However, the EventId is the only thing visible in the event viewer until you double click on the specific event to see more details about it. Therefore scrolling through X completely different entries all with an EventId of 0 is a bit tedious to say the least. So this sort of interface is familiar to the Unix programmers, but possibly a little misleading if they think their work will ever run seamlessly on windows.
My best effort at creating a combined win32 / unix log library has been to provide a call like this:
Which on unix opens the correct localisation file, creates the log message and sends it to syslog/wherever and on win32 sends direct to the event logger
Comments on these ideas?