On Mon, 2008-10-13 at 15:21 -0400, Steve Huston wrote: > Hi folks, > > Thanks for the input on the logging question. > > > From: Carl Trieloff [mailto:[EMAIL PROTECTED] > > From a user perspective, this is what I would want to see. > > > > On Linux --log-output has options of > > > > stderr, stdout, syslog > > > > On Windows --log-output has options of > > > > stderr, stdout, eventlog > > > > Then on Linux, the > > > > --syslog-name NAME (lt-qpidd) Name to use in syslog > > messages > > --syslog-facility LOG_XXX (LOG_DAEMON) Facility to use in syslog > > messages > > > > options appear in the list where they are. > > > > and on Windows > > > > any options for event-log are added. > > This sounds good. > > > From: Andrew Stitcher [mailto:[EMAIL PROTECTED] > > On Fri, 2008-10-10 at 11:04 -0400, Steve Huston wrote: > > > ... > > > I see two ways to handle this, and I am asking for your > > discussion and > > > advice. > > > > > > 1. Remove the 'syslog' value from --log-output and add a > > new option to > > > the platform-specific set; maybe --log-syslog yes|no > > > > > > 2. Leave the options as they are and specialize just the syslog > > > handling inside the code. > > > > > > 3. Don't try to split into common and platform-specific > > options; just > > > maintain completely separate option sets for each platform > > even though > > > 90% of the code will be identical. At least to start... > > > > I think I'd personally prefer a slightly different approach (well a > > variant on #1 I suppose): Introduce a new option which is an > explicit > > logging sink. > > > > The essential problem with the current command line interface > > is that it > > overloads the filename with stuff not related to files at all. So > what > > I'd suggest is something like an extra option to direct > > logging output. > > > > Something like: > > > > --log-to <logfile | syslog | eventlog | ...> > > > > then change the option name a bit for consistency with the log-to > > option: > > This sort of rearranges the problem - I think you're on to something > with the comment that mixing generic and specific logging sink names > is a bit problematic, but I'm nto really up for rearranging things at > this point - I have a big hunk of Windows things to get in before I > can rework too much existing (and working) code. > > > --logfile-out FILE (...) > > > > Actually I'm not 100% we really need option to redirect the syslog > > output, but that's a different discussion. > > > > I'd guess this might be most easily implemented by > > introducing a plugin type architcture for log sinks. > > A like the plugin sort of idea, but I can't justify the effort at this > point getting ready for M4. I am going to move the --log-output to the > platform-specific options. We can revisit this at a later point if > there's further interest or problems.
I like the plugin idea too, and in retrospect I think Andrew's right about --log-output being an unfortunate mix. I'd suggest something like this: drop --log-output and have sink-specific options like --log-to-stderr yes|no --log-to-file <filename> --log-to-syslog yes|no ( and related --syslog options) --log-to-eventlog (eventlog parameters?) (and related --eventlog options) Sinks with simple config like file or stderr can be completely configured with a single option. More complicated sinks like syslog/eventlog can have additional configuration options. Everything related to a given type of sink can be included/excluded by including/excluding options, not need to additionally manage the behavior of a "shared" option like --log-output. Steve, I'm OK with you going around the problem for now by making --log-output system specific, but could you raise a JIRA based on this discussion so we don't lose the good intention to refactor? Making this pluggable will be straightforward once we've reorganized sink-related options into dijoint sets. Cheers, Alan.
