<div class="gmail_quote">On Tue, Mar 3, 2009 at 12:18 PM, Thorbjoern Ravn Andersen <span dir="ltr">&lt;<a href="mailto:ravn@runjva.com">ravn@runjva.com</a>&gt;</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 &quot;corpus&quot;. 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&#39;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&#39;t care whether the wire-format is human readable or not.<br>And for me it isn&#39;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&#39;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 Â &quot;...plus... Tubular Bells!&quot;<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>