On Tue, Sep 24, 2013 at 2:25 AM, Jan Kaluža <[email protected]> wrote:

> On 09/23/2013 09:13 PM, Jeff Trawick wrote:
>
>> On Mon, Sep 23, 2013 at 2:54 PM, Ivan Zhakov <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     On 23 September 2013 22:35, Jeff Trawick <[email protected]
>>     <mailto:[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).
>>
>>
> 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.


That's fine.  Note that when using a separate ErrorLogProvider, a directive
like ErrorLog (belonging to a particular provider) would just be ignored if
ErrorLogProvider was set to something non-default, just as
DbmErrorLogParams might be ignored by the implementing module if
ErrorLogProvider was set to the default.


>
>
>>     --
>>     Ivan Zhakov
>>
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
> Regards,
> Jan Kaluza
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Reply via email to