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 _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
