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!"
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
