<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Aug 4, 2008 at 10:13 AM, Ceki Gulcu <span dir="ltr"><listid@qos.ch></span> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, you've got me convinced. Consider the fix done.</blockquote><div><br>Nice. ;) <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>
For the sake of this and future discussions, let me mention that one of SLF4J's<br>
main selling points is its simplicity. Compared to JCL, SLF4J way of binding to<br>
the underlying logging system is outrageously simple. It covers fewer use cases<br>
than JCL. But, as SLF4J is simpler it is also more robust and as you pointed<br>
out, robustness must be an essential characteristic of a logging framework. In<br>
short, simplicity of implementation matters.<br>
</blockquote><div><br>To quote Albert Einstein: <font class="text">"Make everything as simple as possible, but not simpler."<br>I *love* the way SLF4J/logback binding is done. The same is the case for the xxx-over-slf4j stuff.<br>
<br></font> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
More to the point, the bug under consideration is not insidious. If a client has<br>
cyclical arrays and attempts to log them, their application will crash<br>
immediately with a clear pointer to MessageFormatter.deeplyAppendParameter. They</blockquote><div><br>Hehe, are you really sure about this?<br>Granted, I would do that. And you would do that, too, if you had a problem like this in some library you're using... but I know several developers that would be *sure* that the problem must somehow be their fault, searching hours and hours, while the logging they would need to analyze the problem would be broken ;)<br>
<br>I suggested slf4j and logback to a certain guy at TU Darmstadt so quite some very fresh students with very limited experience are using it right now to log their very first java programs...<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>
will complain about the lack of support for cyclical arrays and we will quickly<br>
provide a fix. Here, I am assuming that non-cyclical arrays during development<br>
do not suddenly become cyclical in production. So instead of supporting cyclical<br>
arrays today, we can provide them tomorrow, but only when a user asks for it.<br>
This is just an application of the "1$ Today Is Worth More Than 1$ Tomorrow"<br>
principle -- avoiding adding features that users don't seem to need today and<br>
hence saving a few cycles of my development time and more significantly a few<br>
brain cycles of people trying to read SLF4J code.<br>
</blockquote><div><br>I understand your point. Feature creep can be a big problem...<br><br>In my opinion there are roughly three kinds of bugs.<br>I'll give you an example for every one:<br><br>1.) Bugs like this one or the original recursive Marker problem that could result in an application crash, no matter how likely or unlikely the scenario for the crash is.<br>
They need to be fixed, ASAP, after identification of the problem and after writing a unit test, of course. I would not call the prevention of a crash an additional feature but a fix of a defect instead. Those are, in my opinion, showstoppers.<br>
<br>2.) A problem like the one I described in my last comment at <a href="http://bugzilla.slf4j.org/show_bug.cgi?id=76">http://bugzilla.slf4j.org/show_bug.cgi?id=76</a><br>This is a situation where I see a problem lurking in the future. I tend to fix such problems anyway just to get them out of my head and prevent future troubles. Chances are that I won't have very much time to spare when such a problem manifests so I'll fix them when I stumble over them.<br>
<br>3.) An inconsistency like <a href="http://bugzilla.slf4j.org/show_bug.cgi?id=93">http://bugzilla.slf4j.org/show_bug.cgi?id=93</a><br>I don't really care if this behavior is changed or not. I just wanted to let you know - so that you *do* know. I, personally, like consistency but this "bug" is really irrelevant. No harm can be done by this problem. <br>
<br>To quote The Pragmatic Programmer: "Don't leave broken windows."<br><br>Concerning bugs like 1.) I'll now try to argue from a different direction:<br>If slf4j/Logback would tear down our web application which is supposed to be online 99.9% then I would be the one with the "chopped off head" because I was the one that suggested the transition away from commons.logging and log4j over to slf4j/log4j and later slf4j/logback. While the chopped off head is surely an exaggeration there are a lot of people that are quite dependent on the proper function of slf4j right now.<br>
<br>So this is also a story about trust. People trust you. <br>Every bug that manifests in an actual application removes a little bit of trust so it's always a good thing to fix a bug *before* it's actually doing harm to someone. I'm not sure about the $1 metaphor in that case.<br>
<br>And last but not least, concerning "we will quickly provide a fix":<br><br>I submitted <a href="http://bugzilla.qos.ch/show_bug.cgi?id=148">http://bugzilla.qos.ch/show_bug.cgi?id=148</a> in April, including a suggested fix, and it hasn't been included into logback yet, neither was there a new version of logback since March.<br>
<br>This isn't meant as criticism at all. <br><br>Really ;)<br><br>I just wanted to use it as an example that "quick" can be quite relative.<br><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>
However, as you observed, the fix is simple and elegant, so there is no point in<br>
procrastinating the implementation of a simple solution.<br>
<font color="#888888"><br>
</font></blockquote><div>Thank you.<br><br>Again, as I said in previous mails, I hope you don't get me wrong as I'm essentially a big fan of your software. I'll stop making remarks about that from now on, ok? ;)<br>
English isn't my first language so there is a certain possibility that something might sound harsh even though it's not meant to be that way.<br><br>Regards,<br>Joern.<br></div></div></div>