On 10/03/2005 09:53 PM, Brian Akins wrote: > Rüdiger Plüm wrote: >
[..cut..] > > but that would not be buffering in the sense that mod_log_config does > it. mod_log_config just keeps appending data to a buffer. in an sql > logger, to "buffer" you would keep a list/array/ring of log lines and > wrap them in a transaction. This cannot be "buffered" in mod_log_config Agreed. [..cut..] > See latest patch :) To be honest I haven't tried it yet, but does apr_uri_parse handle the spaces between the piped log parameters correctly? Furthermore I guess you should use pl = ap_open_piped_log(p, name); instead of pl = ap_open_piped_log(p, name + 1); The "|" does not prefix name any longer :-). [..cut..] > interesting. You could have a "linebuffer" that buffered in a way I > describe above and a "buffer" that does it the current way. This may be > a larger change that we first started. Of course, you could define a > log filter chain: > > LogFilter example "monitor param=somevalue|buffer size=1024|compress|file" > Sounds like a good idea > > and then apply the filter in Custom Log: > > CustomeLog filter://example/logs/some.log common > > filter could supply "/logs/some.log" as user_data to each filter. I guess /logs/some.log is only interesting for the backend. We also need to consider that backend providers might need totally different (compared to filenames) parameter types. Maybe URL's with args. I currently found no solution that makes me really happy in conjunction with logfilters but I will keep on thinking on this. > > Of course, this is a much larger change than I think we are ready to > tackle now. > Yes of course. This would require much changes and will not be done in a quick patch, but it just came up my mind during this discussion and it might be a feature to think of. Regards Rüdiger
