Joern Huxhorn skrev:
I've found no other way beside the TimeoutOutputStream that I'm using now. Any other idea?
Not as such. TCP/IP is very robust especially for dealing with these situtations, which is exactly what you are trying to avoid (so normally you would use UDP in such a situation like Quake and other multiplayer games do).
I am still pondering on a language agnostic receiver. The reason for the XML being uninteresting was because it was much more verbose than the plain serialised byte object?
I wouldn't call it uninteresting ;) It's just more expensive to create such events so I'd only use it if I have to. Are they? How come? Perhaps if using XMLEncoder instead of rolling your own :)
otherwise there's no real point to use XML. I could just define a binary format, right?
THe usual reason for using XML instead of a binary format is that you get the parser for free so you can go language agnostic easily.
Would a sufficiently terse xml-dialect be interesting? I was thinking of having one-character node names and attribute names? (and moving the namespace outside the fragments).
I'm not sure about that. Thinking about a binary format would probably be more worthwhile... Binary formats are rather painful to extend at a later date. Just see how hard it is even with help from the serialization modules.
You may remember that I am in a situation where our production servers are inaccessible and where I want our logs to be both humanly readable as well as reprocessable. I would be very interested in defining a very terse XML dialect for this purpose, as Ceki has demonstrated earlier that my needs cannot be fullfilled by the log4j dtd. I see a good need for a production strength "xml receiver -> sfl4j events" added to the slf4j-ext package (or so) - would it licensewise be possible to adapt your work into this? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"