<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 13, 2014 at 5:38 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14-02-12 03:26 AM, George Joseph wrote:<br>
> In the process of creating the dialplan function AST_SORCERY (a<br>
> companion to AST_CONFIG) I've run into an issue with how AMI interacts<br>
> with sorcery particularly related to objects that can have multiple<br>
> occurrences of the same field like contact in aor and match in identify.<br>
<br>
<snip><br>
<br>
><br>
> Notice the inconsistency? In the config, both contact and match are<br>
> singular but in the output, Contacts is plural, Match is singular. The<br>
> difference comes from how the 2 objects construct the AMI event.<br>
> Contact has custom code that spits out the literal "Contacts:" then the<br>
> list, whereas Identify uses the generic sorcery code which spits out the<br>
> name of the field (hence the singular) and the list.<br>
><br>
> If the fact that one is plural and the other is singular is a bug, tell<br>
> me which is correct (hopefully the singular, see below) and you don't<br>
> have to read further unless you've got some time to kill. If it's a<br>
> feature, read on...<br>
<br>
The returned name should be the name of the field, thus contact.<br></blockquote><div><br></div><div>Yay!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Background:<br>
><br>
> On Monday I started work on the AST_SORCERY dialplan function which<br>
> allows you to retrieve arbitrary fields from a sorcery based config like<br>
> pjsip.conf. The function itself is quite simple. Basically, it calls<br>
> ast_sorcery_objectset_create and iterates over the resulting<br>
> ast_variable list to find the field of interest. Works great for single<br>
> occurrence fields but as I found out, not at all for multiple occurrence<br>
> fields like aor's contacts and identify's matches. As it turns out, the<br>
> structure that defines a sorcery field does have a virtual function<br>
> member for returning multiple occurrence fields as an ast_variable list<br>
> but none of the objects implement it and besides, none of the<br>
> ast_sorcery_object_field_register functions allow you to set it. In the<br>
> end, without coding object-specific logic in AST_SORCERY, there was no<br>
> way to retrieve the multiple occurrence fields because<br>
> ast_sorcery_objectset_create wasn't returning them.<br>
<br>
The multiple_fields functionality is actually exposed, just only through<br>
the regex support.<br>
<br>
> Well, I fixed all of that and now ast_sorcery_objectset_create can<br>
> return an ast_variable list with as many entries for contact and match<br>
> (and any others) as there are entries in the conf file. Works<br>
> great...except for the AMI. I'm told that that an AMI event can't have<br>
> multiple fields with the same name so multiple Contact or Match fields<br>
> wouldn't work. Ok, you've always been able to register a handler that<br>
> spits out a single string for multiple occurrences and you can now tell<br>
> ast_sorcery_objectset_create which behavior you want. Except (to bring<br>
> this back to the beginning), that would change the hard coded "Contacts"<br>
> in the event to the generically generated "Contact". :)<br>
<br>
Do you have unit tests for that? :D<br></blockquote><div><br></div><div>Wrote the tests first. :) One for the function, then updated the others. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> So, can I remove the "s"? Can I, Please?? Or I guess I can still use<br>
> the generic code and do a search and replace in the AMI output buffer<br>
> and add the "s" back in.<br>
<br>
I suppose the question really is... do we make this incompatible with<br>
the past.<br>
<br></blockquote><div> </div><div>Exactly. This really wouldn't have been an issue if it was all internal but since the AMI is an external contract...</div><div style="text-align:center"> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Either way, this'll be good background info for why a patch to add 1<br>
> simple dialplan function is as complex as it is.<br>
><br>
> Bonus Question: Why are aors and auths specified as a single<br>
> comma-separated string where contacts and matches are specified on<br>
> multiple lines?<br>
<br>
Hilarity, that's why. Okay, not really. No immediate answer springs to mind.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div> </div></div></div></div>