2016-02-02 1:32 GMT+01:00 Michael Biebl <[email protected]>: > 2016-01-25 10:00 GMT+01:00 Rainer Gerhards <[email protected]>: > > Hi all, > > > > please note that the (candidate) tarball for tomorrow's release is now > > available at > > > > http://www.rsyslog.com/files/download/rsyslog/rsyslog-8.16.0.tar.gz > > > > If you build packages, it would be nice if you could pick it up and see > if > > it works for you. Any bug reports received within the next 24hrs could > > probably be solved in the actual release. > > > > Note that we do not yet require libfastjson but strongly recommend it. > > 8.17.0 will finally require it. > > > While I can understand the motivation, I do fear that ultimately you, > Rainer, take on another responsibility, i.e. maintaining another > library. > And resources are already stretched very thin. > > This is my main concern of introducing yet another dependency. >
Yes, but itsn't that the case with any new development. Take for example this PR https://github.com/rsyslog/rsyslog/pull/578 It is rougly one third the code lines of json-c, but while json-c is rather simple code, that PR is much more complex. I agree to your point, and as you see I have been hesitant to merge until I find time to at least do a bit of review and get comfortable with it (and I just thought out loud about merging it as "experimental" for that reason). Given the PRs I've merged the past week, I think the body of code is even larger than whole json-c, which is a very small lib. So following the argument, we would ultimately need to stop developing anything new. For reasons given in my blog post, json-c was just the wrong decision when we made it. Things happen. But we must correct it. I can of course try to avoid a new lib. But that would mean I need to have embedded copies in both liblognorm and rsyslog, and find a way to coordinate these when used togehter, and find a workflow that keeps both copies consistent. To me, using common code as a library just sounds like why libraries were invented. Technically, I do not see any way forward with json-c. Even if the correctness problem would be solved, I do not see any way to get decent performance from the variable subsystem. It simply is a no-go. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
