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.

Reply via email to