https://bugzilla.balabit.com/show_bug.cgi?id=246 --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2013-08-20 13:24:28 --- indeed :) I was posting from my phone and was interrupted while typing my answer. anyway, my vision is to use syslog-ng values the same as JavaScript dot notation, which is equivalent to JSON. We already support a recursive JSON dictionary as the syslog-ng message model, even have rudimentary support for types with the latest typehint work by Algernon (not yet integrated). Once we have that and array support in place, our data model would be complete. We even have a means to enumerate properties of a message and do "subselects" of name-value pairs using value-pairs() option available in a number of destinations. Throwing an "official" transport protocol in place (which would be just a combination of json-parser() and one of the already existing transports), we would have a rich event delivery infrastructure, potentially supporting everything from legacy syslog to application specific logging. I'm progressing slowly towards this vision as I'm my limited time is spent in closing the gap between the syslog-ng PE and the OSE trees. See my latest work on the wild card file source stuff that PE has had for years. It's not a simple merging effort as PE/OSE has diverged somewhat in the past and I want much better unit test coverage than is available in the PE implementation. I'd appreciate contributions towards this goal, even though the data structure used to encapsulate LogMessage is not the simplest thing on Earth because of its performance sensitive nature, and adding arrays on top is not simple either. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.