As mentioned in the thread about LoggingEvent refactoring, I think that the underlying problem that should be solved first, is how to transport logging events in and out of a JVM as efficiently as possible. Efficient means at least to me: * Little overhead - both network bandwith wise, and cpu wise * Large amounts of events can be sent fast - the host program is not tied up. * Large amounts of events can be received fast - perhaps a bundle concept? * Supports Unicode (no 8-bit folding) The current approach for the Socketserver is a simple accept-and-fork system where the incoming data is serialized log events. Pro: Data stream is rather compact -> network friendly. Contra: Log events can only originate on a JVM with a compatible version of logback. Jörn, perhaps you'd like to do a more complete writeup on what should be anticipated? Larger datablocks may be acceptible if the data is lightly compressed. My personal preference before actual experiments would be a XML format in a dialect supported by a third party, e.g. XMLDecoder/Encoder or an Apache project, as it is important to delegate the performance work to another team. If we bring ZeroConf into it too for the discovery process it would be nice. The default behaviour of network loggers in Java has not been established yet. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"