Possibility of using IBatchFormatter's Format overload, which accepts IEnumerable<LogEvent> and ITextFormatter

Is your feature request related to a problem? Please describe. From the v8.* sink uses only void Format(IEnumerable<string> logEvents, TextWriter output); method. Method void Format(IEnumerable<LogEvent> logEvents, ITextFormatter formatter, TextWriter output); remains abandoned, what ruins all sinks, built on-top of Serilog.Sinks.Http (for example, sinks for Grafana Loki). Overload with 3 params is used for formatting output in specific way, acceptable by concrete logging systems. LogEvents, passed to the methods, are widely used for generating enriching metadata of logs, what could be used in logging-systems specific query languages.

I understand that Serilog.Sinks.Http is high-abstract sink, but how could this backward combability could be kept?

Additional context Example of sink, which defines own batch formatter (to satisfy vendor-specific API) and build on top of this sink could be found here

[mishamyte]

Yes, I took this risk, that only non-durable sink could be used when I was implementing sink. OK, I got your point and totally agree with it.

A lot of thanks for your work and good luck with the project.

[FantasticFiasco]

I see the problem with IBatchFormatter, that only one of the methods in the interface is used. But, unfortunately, I would lean on removing the method you wish to keep. The reasoning is as follows. There is no chance in hell that a consumer of this library would know that one of the methods where used if the sink was non-durable (the one with a sequence of log events), and the other method was used if the sink was durable (the one with a sequence of strings). Other than that, if you take a dependency on this sink, which you seem to have, while still requiring the full log event in the batch formatter, you would never be able to support a durable version of your sink, because in that configuration you would never receive a full CLR log event from this sink. You would always receive the textual representation created by the specific implementation of ITextFormatter.

As you mentioned, I never intended for this sink to be an implementation detail of another higher order sink. Successfully doing so would be a chance of luck, and brittle as you’ve now experienced, because that was never my intention in the first place. I think your best bet going forward would be to copy the relevant parts from this project to yours, and modify them according to your requirements.