On 24 September 2013 10:06, Jan Kaluža <[email protected]> wrote: > On 09/23/2013 09:30 PM, Ivan Zhakov wrote: >> >> On 23 September 2013 23:13, Jeff Trawick <[email protected]> wrote: >>> >>> On Mon, Sep 23, 2013 at 2:54 PM, Ivan Zhakov <[email protected]> wrote: >>>> >>>> >>>> On 23 September 2013 22:35, Jeff Trawick <[email protected]> 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? > Yes, I suggest to forc ':' suffix for log provider name.
-- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
