On Thu, Feb 13, 2014 at 5:38 AM, Joshua Colp <jc...@digium.com> wrote:
> On 14-02-12 03:26 AM, George Joseph wrote: > > In the process of creating the dialplan function AST_SORCERY (a > > companion to AST_CONFIG) I've run into an issue with how AMI interacts > > with sorcery particularly related to objects that can have multiple > > occurrences of the same field like contact in aor and match in identify. > > <snip> > > > > > Notice the inconsistency? In the config, both contact and match are > > singular but in the output, Contacts is plural, Match is singular. The > > difference comes from how the 2 objects construct the AMI event. > > Contact has custom code that spits out the literal "Contacts:" then the > > list, whereas Identify uses the generic sorcery code which spits out the > > name of the field (hence the singular) and the list. > > > > If the fact that one is plural and the other is singular is a bug, tell > > me which is correct (hopefully the singular, see below) and you don't > > have to read further unless you've got some time to kill. If it's a > > feature, read on... > > The returned name should be the name of the field, thus contact. > Yay! > > > Background: > > > > On Monday I started work on the AST_SORCERY dialplan function which > > allows you to retrieve arbitrary fields from a sorcery based config like > > pjsip.conf. The function itself is quite simple. Basically, it calls > > ast_sorcery_objectset_create and iterates over the resulting > > ast_variable list to find the field of interest. Works great for single > > occurrence fields but as I found out, not at all for multiple occurrence > > fields like aor's contacts and identify's matches. As it turns out, the > > structure that defines a sorcery field does have a virtual function > > member for returning multiple occurrence fields as an ast_variable list > > but none of the objects implement it and besides, none of the > > ast_sorcery_object_field_register functions allow you to set it. In the > > end, without coding object-specific logic in AST_SORCERY, there was no > > way to retrieve the multiple occurrence fields because > > ast_sorcery_objectset_create wasn't returning them. > > The multiple_fields functionality is actually exposed, just only through > the regex support. > > > Well, I fixed all of that and now ast_sorcery_objectset_create can > > return an ast_variable list with as many entries for contact and match > > (and any others) as there are entries in the conf file. Works > > great...except for the AMI. I'm told that that an AMI event can't have > > multiple fields with the same name so multiple Contact or Match fields > > wouldn't work. Ok, you've always been able to register a handler that > > spits out a single string for multiple occurrences and you can now tell > > ast_sorcery_objectset_create which behavior you want. Except (to bring > > this back to the beginning), that would change the hard coded "Contacts" > > in the event to the generically generated "Contact". :) > > Do you have unit tests for that? :D > Wrote the tests first. :) One for the function, then updated the others. > > So, can I remove the "s"? Can I, Please?? Or I guess I can still use > > the generic code and do a search and replace in the AMI output buffer > > and add the "s" back in. > > I suppose the question really is... do we make this incompatible with > the past. > > Exactly. This really wouldn't have been an issue if it was all internal but since the AMI is an external contract... > > Either way, this'll be good background info for why a patch to add 1 > > simple dialplan function is as complex as it is. > > > > Bonus Question: Why are aors and auths specified as a single > > comma-separated string where contacts and matches are specified on > > multiple lines? > > Hilarity, that's why. Okay, not really. No immediate answer springs to > mind. > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
