On Wed, 23 Nov 2016, [email protected] wrote:
Open question to the community: does it really make sense to create a
new repo at this stage?
I'll try to start as clean as possible, but I agree I can start writing
anywhere
Name + Scope
I mean this project will NOT host rsyslog code, so what will it host?
Shouldn't we benefit from rsyslog code and lessons?
I think it can be faced two ways:
- a new/fresh code, without backward compatibility
- a rsyslog-ng branch, with maybe heavy refactoring, but keeping backwards
compat
Perhaps anyone think's another way? Comments are more than welcome.
I see no value in throwing out the existing code.
We have a few gaps to fill, but why start from scratch?
Eliminating backwards compatibility would be a major flaw.
If there is a need to do major refactoring, we can do that in the existing
codebase, but I don't think we have any evidence that there is a need to do
this.
Right now, we have two proposals:
1. create an imhiredis module
2. create a logsend program (or config, or package) that just does the simple
job of picking up log files and delivering them.
#2 may be a new program, or it may be just a config/build of the existing code
There are a number of things that can be improved in Rsyslog today, but we
aren't going to be able to do them if we start by throwing everything away and
recreating it from scratch.
Remember that Rainer does almost all the coding for rsyslog, if he goes to
re-write it from scratch rsyslog will be dead for years.
The biggest, most invasive change we've talked about the need for is the
possibility of replacing the existing variable mechanism. What we have now was
not actually intended as a general purpose variable structure, but rather a way
to deal with json in messages (looking at the cee project). json-c was a major
problem, so it has been forked into libfastjson and a lot of issues fixed. But
it's still something that eats up a lot of CPU (see the performance analysis in
Rainer's paper, 34% of cpu spent in libfastjson functions and 30% spent in
memory management functions, mostly called by libfastjson functions)
But as invasive as this is, it can be done without throwing out the rest of
rsyslog.
David Lang
_______________________________________________
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.
