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. > 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 > 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. > 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. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- 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
