[lumberjack] New Syntax Spec and updated Field list

david at lang.hm david at lang.hm
Wed May 2 23:58:42 UTC 2012


On Wed, 2 May 2012, Dmitri Pal wrote:

> On 05/02/2012 05:17 PM, david at lang.hm wrote:
>> On Wed, 2 May 2012, Balazs Scheidler wrote:
>>
>>> ----- Original message -----
>>>> On Wed, 2 May 2012, Gergely Nagy wrote:
>>>>
>>>>>
>>>>> It complicates both the sender side (do I want to send stuff as proper
>>>>> JSON, or with inline representation?), it complicates things on the
>>>>> consumer side too (do I need to expand inline syntax? if so, it will
>>>>> likely turn into dotted-notation, and then how do I reassemble it back
>>>>> if it needs to be forwarded?), and adds extra work on every level.
>>>>
>>>> I think that the only good reason for doing having the inline stuff is
>>>> for   a template based API. Over the wire it would be far better for
>>>> everything   to be nested JSON so that all recipients only need to know
>>>> JSON.
>>>>
>>>> But when creating an API to generate the logs, figuring out how to
>>>> specify   structure is non-trivial and I can see the desire to be
>>>> able to
>>>> specify   the fully qualified name of a field.
>>>>
>>>
>>> I can understand this desire, however this is what the dotted
>>> notation is good for. E.g. if it's simpler to use a flat namespace in
>>> an API, use that. the mapping between the json structure is quite
>>> standard.
>>>
>>> In syslog-ng I'm planning to use dotted notation when working with
>>> fields as syslog-ng has a flat structure in its event model, but then
>>> generate nested json at the end.
>>>
>>> The same can be done in any logging API.
>>
>> is the only difference between the two notations the fact that the
>> serparator character is '!' instead of '.'?
>>
>> If so, I don't have any strong preference betwen them, but I would
>> think that '.' would be more likley to conflict with other uses.
>
> Yes that was the only reason for picking '!'. I came across conflicts
> when field name has to have '.'.
> I might envision that host name might become a field name in some case
> for example.
> '!" looks much safer to me.

we need to differentiate between the data (which may have any text in it) 
and the field names (where we are saying we want to eliminate a few 
characters, one for the hierarchy indicator)

if JSON already has a standard we should use it, if it doesn't we should 
try to use something that minimizes conflicts.

David Lang
-------------- next part --------------
_______________________________________________
lumberjack-developers mailing list
lumberjack-developers at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/lumberjack-developers


More information about the lumberjack-developers mailing list