Joern Huxhorn skrev:
And "best" is defined as "the most efficient way - preferably platform agnostic".
Ralph is probably hinting at that "efficient" is not necessarily "fastest". I think the core here is if anything else but the raw events needs to be communicated? (Perhaps exchanging timestamps to allow the receiver to normalize, some handshake to ensure that both ends are trusted?) Personally I'd like robustness, and flexibility. Basically my scenario is to have a production server - attach a receiver, grab some log data, and detach it again without notifying or restarting the production server, and that the application being logged is not influenced by this. An analogue would be a Quake 1 multiplayer scenario where players can enter and leave at will, instead of all having to be ready at the start of the game which is what Doom and DukeNukem did. An application restart is rather inefficient :)
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.
Looking forward to hearing about it. I gather the protobuf is open source (haven't done anything but skim the webpage) -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"