On Sun, 2011-02-06 at 13:27 -0800, Matthew Hall wrote:
Since this is a self-contained module, I'm willing to include it in 3.2 (and certainly in 3.3), but I'd like the value-pairs() to be finalized that Algernon is working on. The only reason is that I wouldn't want to handle possible incompatible changes if the interface will change with value-pairs.
Fair enough. Let me know when value-pairs looks good and I can try backporting and testing.
The problem is, we'd pretty much have to backport value-pairs() too, if we want to make the 3.2 tfjson port compatible with 3.3. I'm not entirely convinced that would be worth it, even though value-pairs() is mostly self contained too (at least at the moment, and I don't expect it to grow outside of lib/value-pairs.[ch] and a few lines in the config grammar files [which don't need to be backported to 3.2]).
I wonder if there could also be a way to support binary formats like XDR or Google Protocol Buffers or some other kind of RPC format.
I don't see much that would be against it: template functions are using GStrings as results, and technically, we can have binary data in those. It all depends how the result is used: if the GString-supplied length is used, we're good. If we assume it's a C string, then things will break. It probably wouldn't be a big task to verify that we're 'binary clean' - and once we are, there's nothing that would prevent one from using binary formats.
I'd like to be able to interface syslog-ng with higher level languages for coding complex logic without adding risk of bugs in my code breaking the core daemon if I start hacking out C modules.
I had this idea of making it possible to write syslog-ng modules in various other languages, but so far, I didn't get past the "oh hey, this would be neat" stage. But anyway, I see three ways to accomplish something like this: * "Message passing": output in a format that the other language understands easily, and connect the two that way. * Embedded interpreters: Embed python/perl/lua/whatever interpreters, and export selected syslog-ng internals into the language. * Implement language bindings for libsyslog-ng, and write loaders for the various languages (a'la dlopen()). But these are merely vague plans, and I'm not even sure either of these is a good idea to begin with. -- |8]