Rainer Gerhards schrieb:
The biggie, at least IMHO is Unicode support. While I followed every IETF move with rsyslog (in fact, I used it partly for prototyping), I was hesitant to include Unicode support. That has the potential to break many existing applications.
Indeed. Having Unicode in logfiles also requires all used shell tools and parsers to handle it correctly.
Also, the new log line format is something that can break existing log parsers, so one needs to be very careful about how it is implemented.
The usual transition problem: noone uses the format --> no parsers, and no parsers --> noone uses the format.
Apart from that I would think users with centralized logging or automatic analysis would be the first to appreciate the enhanced format; while desktop users who check their logs manually simply do not care if the lines look a bit different. Since the new format (-protocol) is a real superset, It is also easy to provide a filter (a sed or awk command to re-format) for compatibility.
Another problem is the API and the handling of structured data (name=value-pairs). I expect all applications to build their own structured data-strings and pass them as messages to syslog(3), just to be portable. -- Thus a syslog library which modifies the structured data (to insert additional information) will have to parse every message. :-/ In the long term it would be nice to introduce a new API call which receives the structured data as a seperate argument.
-- Martin