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

[Mauro Sergio Ferreira Brasil]

Thanks a lot again for the help and the info regarding patch submission.

Best regards,
Mauro.


Tilghman Lesher escreveu:
> On Monday 17 August 2009 01:10:00 pm Mauro Sergio Ferreira Brasil wrote:
>   
>> 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.
>>>       
>> 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.
>>     
>
> We're very open to suggestions, and if you wanted to suggest patches, you're
> welcome to do in the appropriate forum, which is typically the bugtracker.
> However, if you're discussing design choices, then this is the right forum.
> In this case, you've proposed something that is not compatible with the
> current design, and thus, it was rejected, albeit with my suggestion on a
> better method to achieve your goals.
>
>   
>> 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.
>>     
>
> In the current case, the realtime architecture is already capable of
> handling arbitrary parameters.  There are plenty of other APIs which
> are not as flexible and may benefit from future modification, however.
> That's not to say that there aren't possible modifications that might be
> useful in the realtime architecture, but the bar tends to be a lot higher
> than for other parts of the code.
>
>   
>> 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.
>>     
>
> That's perfectly reasonable, but remember that we have a design goal
> to keep the codebase as manageable as possible, even when that means
> rejecting patches from contributors, because the methodology employed is
> not flexible enough to be generally useful to the rest of the community.  In
> such cases, we may a) reject the contribution outright, b) suggest
> modifications that would make the contribution more generally useful, or
> c) point you to another method that can be used to accomplish the same
> goal.
>
>   

-- 
__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