On Fri, 2008-07-18 at 13:55 -0400, Steve Huston wrote: > Hi folks, > > Some ideas related to logging - I'd like some direction/feedback... > > > > 3.- Solaris doesn't define the FTP and LOG_FTP syslog > > > categories. Fixed with a #ifdef/#ifndef clause. > > > > Right... I am looking at this area today wrt Windows since Windows > has > > none of this stuff and I fear it's creeped too far into > > platform-agnostic code. I'll send another email on this later. > > It seems that the portability problems in the logging area are > primarily related to syslog, particularly in: > > - Specifying options to configure logging > - Logging sink to syslog > > I think I can see a way to remedy both, and I'm hoping for some input. > > Options... If I read the code correctly, qpid::log::Options inherits > from qpid::Options. Qpid::log::Options adds a bunch of available > options, most of which are portable and the syslog-related ones, which > are not. Might it be possible to add another layer, such as > qpid::log::posix::Options, qpid::log::windows::Options, etc. that > inherit from qpid::log::Options? Then move the syslog options setup to > the posix::Options, and add Windows ones to that area. > > Logging... The SyslogOutput struct could be moved to a posix-specific > area, maybe qpid/log/posix?
I think the approach you've outlined here is about the correct platform specific/platform independent split for logging. Given that the Windows/Unix system logging components are so different I don't think you could sensibly try to make them look similar. > > This presents a bit of a challenge to documentation since there would > then be some options that only work for Linux/Solaris/etc. and some > that only work for Windows. But that's unavoidable if the full range > of options remains available, and I think it's a good idea for them to > remain. As above I don't think documentation difficulty should stop us from taking advantage of the native platform features at this level. If it turns out to be very confusing to users we'll have to investigate ways to make common use cases the default or use similar options on each platform which abstract away the platform differences in some way. > > Ideas? I can begin working this out this afternoon if I get some > feedback... Give it a go! Andrew
