[asterisk-dev] Retrieve current channel from inside ARA driver method ...

[Mauro Sergio Ferreira Brasil]

It seems I was not very happy on my example given that the channel won't 
be present and/or usefull on "config_load_func" and "realtime_update" 
methods.

Anyway, what I would like to know is how open is Asterisk's code base 
decision board to suggestions like this?
I mean, not exactly like this because I agree is there some wrong points 
on my suggestion.

The point is: Is it possible to get some patch sent to you guys and see 
it applied if it's somehow replicable (even when it doen't aid to 
current implementations) ?
For example: a patch to add the channel to methods of realtime 
responsible for retrive the dialplan information can be usefull for 
other people that decides to make their own proprietary drivers like us, 
while this change don't demand any kind of test and/or validation on 
drivers already created that will only disrespect this new parameter.

I'm asking this question because we use to contribute with other 
open-source projects here and we try to always validate the possibility 
to get some patch applied when we see that it can be usefull to other 
people, on a effort to keep our codes as similar as possible to the 
original ones to facilitate new patch creation and submission.

Thanks again for everything and best regards,
Mauro.




Tilghman Lesher escreveu:
> On Monday 17 August 2009 08:33:36 am Mauro Sergio Ferreira Brasil wrote:
>   
>> Tilghman Lesher escreveu:
>>     
>>> Well, most of the information you're looking for is actually passed back
>>> to the realtime driver already, as parameters to the query.  That's true
>>> for both context and extension.  The only part that isn't passed back is
>>> callerid number.  That could be added without too much trouble to the
>>> pbx_realtime module, although it would not be backwards compatible with
>>> most
>>> implementations.  In addition, I'd suggest using something like the
>>> res_config_curl driver to make your extra evaluation on the backend
>>> easy.
>>>       
>> I'm not completely sure whether your suggestion is to add the additional
>> CALLERID information to the list of parameters that are already being
>> passed to realtime procedures, because on that case it will get
>> automatically added to SQL query statement, won't it ?
>>     
>
> Only if your backend goes directly to an SQL query statement.  As I detailed
> above, it's certainly possible to substitute a middleware piece in between
> the realtime backend and your database, and as I've indicated, there's already
> a driver that lets you do exactly that.
>
>   
>> Anyway, I would like to place a question that will be more profitable:
>> It would be acceptable to asterisk staff a change on realtime so the
>> channel parameter gets forwarded to all realtime configuration routines
>> ("config_load_func", "realtime_var_get", "realtime_multi_get" and
>> "realtime_update") declared at "main/config.h" ? (I know that this will
>> demand changes on some methods from "pbx/pbx_realtime.c" so the channel
>> can indeed be forwarded, and on all implemented drivers as well. But a
>> controlled change, I think.)
>>     
>
> No, we're not going to do that.  The callerid is the only extra information
> that you need, the channel is not necessary, and in some cases, the channel
> does not even exist when realtime is called.  It is therefore inappropriate to
> demand that a channel parameter be passed.
>
>   

-- 
__At.,                                                                                                                             
   _
 
*Technology and Quality on Information*
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ mauro.brasil at tqi.com.br <mailto:@tqi.com.br>
: www.tqi.com.br <http://www.tqi.com.br>
( + 55 (34)3291-1700
( + 55 (34)9971-2572

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090817/204b54d0/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMMI_2.jpg
Type: image/jpeg
Size: 1705 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090817/204b54d0/attachment.jpg