We are starting to ship Lua decoders with Heka; we've nearly finished 
implementing a syslog decoder in lua that will ship w/ Heka. We're 
still ironing out all the kinks, but hopefully over time the corpus of 
Lua plugins that you get out of box will be considerable.

On Fri 22 Nov 2013 10:05:20 AM PST, Jordi Boggiano wrote:
> In docs/source/configuration.rst:
>
> > +    representation.
> > +
> > +    If the field specified a type, but the extracted value cannot be converted
> > +    into that type, decoding will fail and the message will be dropped. It is
> > +    possible to specify an optional type by appending a question mark after
> > +    the type name, e.g. `Requests|count|int?`. In these cases, if the
> > +    conversion fails decoding will be considered to have succeeded and the
> > +    message will still be processed, but the specified field will not be
> > +    created on the message object.
> > +
> > +    Consider the following sample message_fields section::
> > +
> > +        [my_decoder.message_fields]
> > +        Type = "%Type%Decoded"
> > +        Requests|count|int = "%Requests%"
> > +        ResponseCode||int? = "%RespCode%"
>
> That's probably true, but indeed the "lua in toml" thing crossed my
> mind earlier, because it's a bit of a pain to have many files to deal
> with, until I move it all to puppet configs anyway. It's a dumb gut
> feeling thing, but I think for newcomers it's a bit nicer if they
> don't have to dive into lua sandboxes right away. You're probably
> right though. It'd just be nice to identify common lua scripts at some
> point and turn them into go decoders (if we can make them as
> performant as the lua ones, which I'd hope is possible), or at least
> ship some lua ones with heka, just to set common patterns and avoid
> forcing everyone to maintain a copy of the same stuff.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/mozilla-services/heka/pull/531/files#r7863479>.
>