On Tue, 24 Sep 2013 08:06:59 +0200 Jan Kaluža <jkal...@redhat.com> wrote:
> On 09/23/2013 09:30 PM, Ivan Zhakov wrote: > > On 23 September 2013 23:13, Jeff Trawick <traw...@gmail.com> wrote: > >> On Mon, Sep 23, 2013 at 2:54 PM, Ivan Zhakov <i...@visualsvn.com> > >> wrote: > >>> > >>> On 23 September 2013 22:35, Jeff Trawick <traw...@gmail.com> > >>> wrote: > >>>> > >>>> In 2.4 the syslog logging wouldn't be implemented as a provider, > >>>> the ErrorLog directive parser would be different, new structure > >>>> fields would be at the end, but otherwise it shouldn't be hard :) > >>>> > >>> > >>> It could be theoretical backward compatibility issue if someone > >>> uses log named the same as some provider. Why not add new > >>> directive LogProvider? > >> > >> > >> I've never seen a log file within the ServerRoot directory. The > >> risk of such a configuration and it matching a provider actually > >> loaded seems low enough (and with an easy enough workaround) to > >> forgo having a different configuration directives between > >> 2.4/next-major-release. > >> > >> But maybe > >> > >> ErrorLogProvider provider-name arg1-n > >> > >> would be nicer anyway (same in all applicable branches). > >> > > Another option to use ':' to separate log provider and arguments. > > Like ErrorLog syslog:arg1-n. It could be useful when log destination > > specified in command line using '-E' option: > > httpd -E "syslog:" or httpd -E "eventlog:Apache2" when Windows Event > > log provider will be implemented. > > That's what I use in my patch currently in trunk. You can even write > "ErrorLog file:logs/error_log", but for backward compatibility > "ErrorLog logs/error_log" works too. > > Or do you mean you would force ':' suffix even when there are no > arguments for log provider? You realize : is a problematic overload for Netware (and in theory for Win32 unless you dodge the X: single-char drive letter bullet)? What about a "[provider]path syntax" instead? Any other good ideas? A notoriously bad idea was the (size) overload of the SSLSessionCache directive.