[asterisk-dev] CLI filtering

[Steve Edwards]

On Thu, 18 Jan 2007, Steven Critchfield wrote:

> On Thu, 2007-01-18 at 13:33 -0800, Steve Edwards wrote:
>> On Thu, 18 Jan 2007, Steven Critchfield wrote:
>>
>>> Maybe go a different route, maybe try "tagging" log events. Say each
>>> call to ast_log would have an extra arg which is an array of tags for
>>> which we can filter on. In those tags, we can place any number of
>>> interesting information such as channel, callerid, IP address, system
>>> name, or subsystem generated from. Then you could just do a quick check
>>> against the tags to see if it is one you want to exclude or include for
>>> the filtered list.
>>>
>>> I don't know what the performance hit would be like for this way of
>>> doing it. But the programming effort wouldn't be too much. A few lines
>>> in ast_log to accept extra arg for tags, code to look for and deal with
>>> tags. Of course then the going through all the ast_log calls and adding
>>> the tags will be a bit of a chore though.
>>
>> The "tags" concept seems to be very workable to me. It can be added to
>> the body of ast_log() first, and then added to each invocation of ast_log
>> piecemeal and containing the information relevant to that section of code
>> be it a literal, a channel number, or a caller id number.
>>
>> It's been a while since I've played with the va_start/va_end stuff. Can
>> you tell how many arguments were consumed by vfprintf (for example) and
>> then handle the remaining arguments as tag pointers?
>
> I was reffering to taggin as in the same ideas behind some web2.0 apps.
> Tags are meta data that you can add that don't change the current
> information. Tagging is used on web apps to filter or classify
> information.
>
> I don't know if I would want to have the tags be displayed to console as
> your question about vfprintf makes me think you where interested in. I
> think maybe it might be interesting in the saved logs for later
> dissection. But for the CLI, it would be more information added to the
> hydrant that doesn't help one get their job done.

We're on the same page. The tags would not be included in the console 
output. My reference to vfprint was because that is what is used in 
ast_log to build the output string. Additionally, passing the tags as 
additional optional arguments means that you don't need to build a tag 
list nor free a tag list with each ast_log invocation -- the call frame 
will do it for you when ast_log returns :)

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000