On 28.02.2009, at 21:44, Thorbjoern Ravn Andersen wrote:
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 :)
I've done some more benchmarking concerning purely serialization/
deserialization without any disk I/O, i.e. using just byte[].
http://apps.sourceforge.net/trac/lilith/ticket/28
the last table at the bottom.
That's actually quite interesting... I didn't expect that using my own
XML Serializer + compression would actually result in smaller data
size than using java serialization + compression.
Even uncompressed, my Serializer doesn't produce much more bytes than
java serialization.... I didn't expect that...
However, creation and handling of XML is still much slower than pure
java serialization - which doesn't surprise me at all.
My own implementation (using StAX) is a lot faster than the generic
java.beans.XML one, though.
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.
The main problem with java serialization is IMHO that it's not
possible to *somehow* load older versions of a class. If you change a
class and change it's serialVersionUID then you have no chance to load
any previously serialized objects. No chance at all. That's quite
evil...
To do something like this one would need to reimplement the class,
with a different name, and implement conversion from old to new.
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.
Have you had the time to check my xml format? While it's not exactly
terse ;) it's definitely human-readable.
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?
My code is licensed under LGPL v3 so this shouldn't be a problem.
Since I'm the only developer I could grant any license, anyway.
I'm not sure what you mean with "slf4j events", though. You mean
"logback" instead of "slf4j", right?
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
