On Mar 2, 2009, at 11:51 AM, Ceki Gulcu wrote:
Ralph,
You are right to note that the subject line is more general than the issue of data encoding, a.k.a data binding. Joern and I seems to be focused on the data binding part of the general problem because as Joern's observes, any generic RPC-type of solution is bound to be slower than a simple TCP socket approach which implies zero protocol overhead. The socket appender approach might not be the most user-friendly or reliable but it is bound to be the fastest. The only remaining issue then (having fixed the transport mechanism to basic TCP socket) is data binding.
What is the essence of your objection? Do you think we are wasting our time or is there something else? :-)
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. 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. 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? What if I want to communicate the locale or timezone of the client to the server? 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. And the cost of serializing a method where one of the parameters is the LogEvent probably isn't even measturable vs the cost of serializing the event itself. So my point is simply that if I was doing this I would have the SocketAppender use the service interface to establish the connection with whatever parameters are desired and then use the service to invoke the method to send the event. Doing this also allows you to create different appenders that use the same service one of which might be on top of Spring remoting so that any of its remoting implementations could be used. On the server side they would call the same implementation class as what the SocketAppender ends up interacting with. Does that clear it up? Ralph