Exactly. We are just trying to find a less fragile approach than serialization for the events sent using SocketAppender (or my multipex-appenders). Ideally, it should be platform- and programming-language-neutral and shouldn't perform much worse than java serialization. protobuf seems to be a ideal candidate from what I've read so far. I'll definitely give it a try. While this is just a subset of "send this logging event there" I had the impression that the question of transport was already solved more or less. There's little alternative to a message based approach (int containing size of data followed by data bytes) if Java serialization is not used. Any kind of RMI will *definitely* be slower than this approach and we should evaluate it as an additional possibility after implementing the high-speed one. Joern. Ceki Gulcu wrote:
Hello Ralph,
In a different context I would have completely agreed with you. In this case however, the service is already known. It's always assumed to be a variant of "send this logging event there," is it not?
Ralph Goers wrote:
The only response I really can have to this is that it is focusing on the wrong thing. If the desire is to allow Logback to accept remote LogEvents then would should be identified first is the service that would be used. Once you have that you will determine just how you want to implement the service. For that matter, it might be decided that choose to accept multiple ways to connect. This is the only place serialization should come into the picture - simply as a byproduct of what you choose to expose. And in many cases users of the service shouldn't or wouldn't even know what serialization technique is being used. They just call the client API passing in their language's equivalent of the LogEvent.
Ralph