<div class="gmail_quote">On Tue, Mar 3, 2009 at 12:18 PM, Thorbjoern Ravn Andersen <span dir="ltr"><<a href="mailto:ravn@runjva.com">ravn@runjva.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ceki Gulcu skrev:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As there are certainly pros and cons for each serialization approach,<br>
instead of the debate eventually degenerating into a religious<br>
argument, we are likely to be better served by basing comparisons on<br>
the same logging event data collection, which in the compression world<br>
is called a "corpus". At present time, we do not have a logging event<br>
corpus. Just as importantly, logback currently lacks a format for<br>
storing the said corpus. Given that this corpus will serve as a<br>
yardstick for a long time, and performance is not an issue, a human<br>
readable text format such as XML seems like a reasonable choice.<br>
<br>
Is anyone interested in providing a corpus?<br>
<br>
</blockquote></div>
....<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Having said that, defining a corpus seems to me as being the most<br>
pressing issue at this time.<br>
<br>
Once we settle on a corpus, we can more objectively debate the merits<br>
of such and such serialization strategy.<br>
<br>
</blockquote></div>
If I understand you correctly you basically say there is a need for a standardized set of event data.<br>
<br>
After thinking this over it might be better to have code generating the events instead of them being stored statically on disk. This is to avoid setting any API in stone except the slf4j interface which by now should be settled.</blockquote>
<div><br>I was thinking the same thing. Having some code that generates a pre-defined set of logging events. <br><br>Side note : I don't think we should be looking for THE wire-format for logback events, because different projects will have different needs.<br>
For example, I don't care whether the wire-format is human readable or not.<br>And for me it isn't absolutely necessary that the receiver can re-construct an *exact* LoggingEvent from the payload.<br><br>Maarten<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
(What if the internal representation of a stack trace is changed or similar? Just happened, might happen again :) )<br>
<br>
A test suite might then build all the events for a given test in memory and then do the actual testing (as would have been done anyway if read from XML)<br>
<br>
That said. What would be reasonable test suites?<br>
<br>
* A million events with almost no text?<br>
* A million events with very large texts (using full unicode set?)<br>
* Lots of exceptions?<br>
* Large MDC's?</blockquote><div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
What do those with experience in large data sets say?<div class="im"><br>
<br>
-- <br>
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"<br>
<br>
_______________________________________________<br></div><div><div><span id="q_11fcc209961e7de8_6" class="h4">- Show quoted text -</span></div><div class="h5">
logback-dev mailing list<br>
logback-dev@qos.ch<br>
<a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank">http://qos.ch/mailman/listinfo/logback-dev</a><br>
</div></div></blockquote></div><br>