Is there a way to iterate var_event or do I need to add one?
Simon On 10/2/08 11:52 AM, "Anthony Minessale" <[EMAIL PROTECTED]> wrote: > use a hash to store the vars. > we have a hashtable you can see being used in zap_io.c > > > > On Thu, Oct 2, 2008 at 1:21 PM, Simon Capper <[EMAIL PROTECTED]> wrote: > >> 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 >> > > _______________________________________________ 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
