Hi Ralph, Ralph Goers wrote:
I'm simply trying to understand what problem you are solving. I also think your assumption regarding the socket approach being the fastest is correct only under the simplest of circumstances. Finally, while the SocketAppender definitely clears up the client side, I haven't seen any discussion about what it is connecting to except that it is a Logback running remotely. A remotely running Logback was just one of Thorbjoerns ideas. The main point of *this* thread - at least as I understood ;) - is to find the "best" solution to encode and decode Logback events.
And "best" is defined as "the most efficient way - preferably platform agnostic".
Frankly, that is the part I find most important and why I'm making any kind of issue out of this. If you are simply looking to improve the existing SocketAppender without providing the other end of the connection, then I apologize and you can ignore everything I've said. I, for one, will implement both sides in Lilith (the SocketReceiver) and the related multiplex appenders. I'll also try to implement anything that is done in Logback I'm quite interested in this topic because I'll also use the best solution as my native file format. It looks like it will be protobuf but I haven't finished the serializer/deserializer, yet. The generated API is very nice, btw. Let's assume you use a SocketAppender and connect to something listening for some kind of serialized LogEvent. What if the client wants to dictate to the server whether it should get control back immediately after the event is received or wait until the event is procesed? I think that isn't the task of the client (the logged application) at all. Logging should simply log, everything else is, more or less, view or usage of the event and should be handled on the receiver side. What if I want to communicate the locale or timezone of the client to the server? I've lost you there. You want to communicate the locale or timezone of the client (the logged application) to the server (the receiver of the events)? I know, it's just an example, but I want to make sure I understood it correctly. I'm pulling this off the top of my head but hopefully you get the idea that by specifying the service interface that you get more flexibility for enhancement down the road. There *is* no service interface. Any type of service in addition to simply receiving events would create an delay.
Joern.