On 11/04/2012 11:58 PM, da...@lang.hm wrote:
> On Sun, 4 Nov 2012, da...@lang.hm wrote:
>
>> On Sun, 4 Nov 2012, Risto Vaarandi wrote:
>>
>>> 2012/10/20<da...@lang.hm>:
>>>> On Sat, 20 Oct 2012, Risto Vaarandi wrote:
>>>>
>>> hi David,
>>> I have completed some work on the alpha version of the next release,
>>> and it supports returning hashes from PerlFunc patterns. If the user
>>> defines a custom parsing scheme inside PerlFunc pattern, keyword=value
>>> pairs can now be returned as named match variables with a single hash.
>>> However, there are still few things I'd like to clarify. Perl regexp
>>> named captures assume that a name consist of alphanumerals and
>>> underscores (i.e., each name character must match \w) which is also
>>> the case for LumberJack. Nevertheless, Perl also assumes that named
>>> capture never begins with a number. Does LumberJack impose a similar
>>> restriction? This restriction allows for one nice optimization --
>>> internally, named and numbered match variables can be stored in one
>>> hash table (for the latter, numbers are used as keywords).
>>> As a separator, I think it is quite easy to allow the use of ! inside
>>> variable names.
>>
>> Lumberjack hasn't specified this, but since this is a very common limitation
>> for variable names, I think it's a very reasonable thing to do.
>>
>> Nothing that Lumberjack has specified would violate this.
>>
>> I'll post to that list?
>
> The initial reaction I'm gettig back is that this wasn't discussed, but
> they have are very strongly in favor of prohibiting leading numbers in
> field names.
>
> David Lang
>
It is good to know that. The only point of potential clash is the SEC's
internal variable $+{_inputsrc} which holds the filename where the event
came from. When introducing this variable, I had an idea of having _
prefix reserved for future special variables set by SEC.
Another issue is the use of delimiting characters in variable names. I
am thinking of allowing !, but if support for referencing cached
variables is added, a "cache_entry.varname" type of syntax would be
required. For delimiting entry and variable names, I was thinking of
colon and dot, but are there any other suggestions? I'd like to have a
delimiter which wouldn't be conflicting with some other structured log
delimiter in the future.
Any proposals or ideas?
with kind regards,
risto
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
