[syslog-ng] [PATCH] tfjson: $(format_json) template function implementation.

[Gergely Nagy]

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]