On 09/23/2013 09:13 PM, Jeff Trawick wrote:
On Mon, Sep 23, 2013 at 2:54 PM, Ivan Zhakov <i...@visualsvn.com
<mailto:i...@visualsvn.com>> wrote:
On 23 September 2013 22:35, Jeff Trawick <traw...@gmail.com
<mailto: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).
I used ErrorLog directive to stay compatible with current syslog
configuration, but if you don't see problems with breaking "ErrorLog
syslog" in trunk, it should be OK to use different directive for providers.
I'm not sure I see some new compatibility problems with use of ErrorLog
directive (except the problem when admin tries to name his log file the
same name as already used by some provider, but this problem is here
already with "syslog").
Btw, what would be the semantic of "ErrorLog" when "ErrorLogProvider"
gets implemented? Will it be just alias for "ErrorLogProvider file
logs/error_log"? In this case, if we don't mind so much about backward
compatibility in trunk, I still think just "ErrorLog" directive for
setting both provider and arguments is cleaner solution.
--
Ivan Zhakov
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Regards,
Jan Kaluza
