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

[Tilghman Lesher]

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.

-- 
Tilghman