I see how the var_event mechanism works. Are you ok with new openzap functions to set/get the vars on the channel, called from outgoing_channel().
zap_channel_add_var(zap_channel_t *zchan, char *var_name, const char *value) const char * zap_channel_get_var(zap_channel_t *zchan, char *var_name) And new fields in zap_channel struct to hold the data char * user_vars[]; int num_user_vars Simon On 10/2/08 10:18 AM, "Anthony Minessale" <[EMAIL PROTECTED]> wrote: > The difference openzp is itself also an abstraction layer so you need to > pass it down. > > I *will not* violate scope like that..... > > so the only thing I am ok with is adding channel variables to the openzap > channels. > Then you can either set them all from the vars_event in the mod_openzap > outgoing_channel routine > or with a callback via the core set_variable mechanism. > > Then your signaling mod could get the variables by name when it was needed. > > you will learn to understand that due to the years of torture from asterisk > and it's knotted up api that is somehow called an abstraction layer, I will > not bend on scope issues. Things like this are exactly what went wrong > there. > > > > > > On Thu, Oct 2, 2008 at 11:04 AM, Simon Capper <[EMAIL PROTECTED]> wrote: > >> The variables would be set before the call by another app, its analogous to >> setting a sip_x variable and having it appear in the sip signaling, don't >> need a callback. >> >> The parameters are (so far): >> Ring type: (cadences index to ring the phone with) >> Phones to ring list: (proprietary for my ozmod module, don't think it >> should >> be in the library) >> >> Maybe have a variable "opanzap_<variable_name>" that mod_openzap looks for >> and adds to the zchan structure by passing a custom variable array to >> zap_channel_open() then the ozmod can read it. >> >> Simon >> >> >> On 10/2/08 6:11 AM, "Anthony Minessale" <[EMAIL PROTECTED]> >> wrote: >> >>> That would pretty much violate the whole scope of the library. It's not >>> supposed to even know there is a such thing as FreeSWITCH to get >> variables >>> from. There could just as easily be a chan_openzap for asterisk (*WINK* >>> *WINK* anyone? buelleur?) >>> >>> What exactly do you need them for? >>> >>> The most elegant way would be for the FS core to allow endpoints >>> (mod_openzap) to register a callback to be called >>> when a variable is set on that channel, then add the concept of channel >>> variables to openzap zchans >>> >>> so then when FS had a channel variable set it mod_openzap would in turn >> set >>> it on openzap zchan and the blind abstraction would be preserved. >>> >>> >>> >>> >>> On Thu, Oct 2, 2008 at 2:42 AM, Simon Capper <[EMAIL PROTECTED]> wrote: >>> >>>> I want to access channel variables from an ozmod module in openzap. >>>> I can't see a way to do it in the current code. >>>> >>>> I'd like to add the feature and provide a patch for openzap when I'm >> done. >>>> I'm thinking of adding a void pointer that could be passed down via >>>> zap_channel_open that could be then be used from the ozmod modules? >>>> Mod_openzap would set the pointer to a function that would give access >> to >>>> channel variables. Thoughts? >>>> >>>> Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeswitch-dev mailing list >>>> [email protected] >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>> http://www.freeswitch.org >>>> >>> >>> >> >> >> >> _______________________________________________ >> Freeswitch-dev mailing list >> [email protected] >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> > > _______________________________________________ Freeswitch-dev mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
