[Lognorm] [rsyslog] liblognorm

[Rainer Gerhards]

On Thu, Nov 28, 2013 at 11:56 AM, Pavel Levshin <pavel at levshin.spb.ru>wrote:

>  Rainer,
>
>
> I see you are preparing for 1.0.0 release of liblognorm. Libestr removal
> from internals can be postponed to next minor release, but we need to
> establish external interface. Instead of current definition, which is
>
> int ln_normalize(ln_ctx ctx, char *str, es_size_t strLen, struct
> json_object **json_p);
>
> I propose this:
>
> int ln_normalize(ln_ctx ctx, const char *str, size_t strLen, struct
> json_object **json_p);
>
> Why use es_size_t, if we are gettind rid of libestr?
>

ahh... excellent point, I have to admit I overlooked it. es_size_t has the
advantage (IMHO) that it is 32 bits and saves us the overhead of passing 64
bits around. I cannot see any reasonable case where we have >2gig messages.
How about using uint32_t instead (or just plain int, but...).

You were right in time to prevent publishing of the package ;)

Rainer

>
>
> This is a reminder, just in case.
>
>
> --
> Pavel Levshin
>
>
> 25.11.2013 12:24, Rainer Gerhards:
>
>
> On Sun, Nov 24, 2013 at 11:35 AM, Pavel Levshin <pavel at levshin.spb.ru>wrote:
>
>>
>> Done, in the same branch on GitHub:
>>
>> https://github.com/flicker581/liblognorm/commits/master-json-c
>>
>>
>>
>  Thanks, already merged. I will later today see that I integrate the
> mmlognorm changes, tying things together. It will initially go into v8.
>
>
>>  Also, I have written a brief document on current rulebase syntax and
>> field types. As a user, I would say that liblognorm lacks proper
>> documentation, and this doc is better than nothing. It is not sufficient,
>> though.
>>
>>
>  full ack, but there is so much to do and so little time. And nobody
> wants to do the doc, so...
>
>  thanks for this effort, it's definitely useful.
>
> Rainer
>
>>
>> --
>> Pavel Levshin
>>
>>
>> 23.11.2013 0:33, Rainer Gerhards:
>>
>> Always looking for backward comp, i'd say create a new one.
>>
>> Sent from phone, thus brief.
>> Am 22.11.2013 21:19 schrieb "Pavel Levshin" <pavel at levshin.spb.ru>:
>>
>>>
>>> 22.11.2013 21:53, Pavel Levshin:
>>>
>>>
>>> Please note that I've just found a regression in my code: it is unable
>>> to strip quote marks from "quote-string" fields. I need to redo this part.
>>>
>>>
>>> It is fixed now.
>>>
>>> I really feel that we need to implement some facility to parse
>>> comma-separated logs, where a field can have zero length. It is easy to do,
>>> and it is a quite common log format (I'm using it, for example). Now,
>>> liblognorm is unable to parse it. There are two ways:
>>>
>>> - change char-to behaviour to allow zero-length matches
>>> - create a new field type, based on current char-to
>>>
>>> What to prefer?
>>>
>>>
>>> --
>>> Pavel Levshin
>>>
>>>
>>>
>>> _______________________________________________
>>> Lognorm mailing list
>>> Lognorm at lists.adiscon.com
>>> http://lists.adiscon.net/mailman/listinfo/lognorm
>>>
>>>
>>
>> _______________________________________________
>> Lognorm mailing listLognorm at lists.adiscon.comhttp://lists.adiscon.net/mailman/listinfo/lognorm
>>
>>
>>
>> _______________________________________________
>> Lognorm mailing list
>> Lognorm at lists.adiscon.com
>> http://lists.adiscon.net/mailman/listinfo/lognorm
>>
>>
>
>
> _______________________________________________
> Lognorm mailing listLognorm at lists.adiscon.comhttp://lists.adiscon.net/mailman/listinfo/lognorm
>
>
>
> _______________________________________________
> Lognorm mailing list
> Lognorm at lists.adiscon.com
> http://lists.adiscon.net/mailman/listinfo/lognorm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.adiscon.net/pipermail/lognorm/attachments/20131128/6878c7d9/attachment.html>