<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 11:53 PM, Kevin Harwell <span dir="ltr"><<a href="mailto:kharwell@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kharwell@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">kharwell@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 6, 2013 at 11:27 PM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div>On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell <span dir="ltr"><<a href="mailto:kharwell@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kharwell@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">kharwell@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 6, 2013 at 7:09 PM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell <span dir="ltr"><<a href="mailto:kharwell@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kharwell@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">kharwell@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Fri, 2013-12-06 at 14:21 -0700, George Joseph wrote:<br></div>
<snip><br></blockquote></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br></blockquote></div><div>Not suggesting separate lists for each object type. What I'm really suggesting is a hashtable for each of the output mechanisms. One for CLI, one for AMI, etc. Each object (endpoint, aor, auth, etc) registers a single cli formatter, single ami formatter, etc. The key for the hastables is the sorcery object type. So, for example, if the CLI command processor had an aor object it would do a simple table lookup in the CLI formatter registry for "aor" to get the aor formatter. In fact, it doesn't even have to know it's an aor because it can just lookup by details->object->type.</div>
</div></div></div></blockquote><div><br></div><div>Aaah I think I see now. Once you have the formatter you pass in the flag to switch off the various formatter view(s) (summary, detail, other...). A few possible things come to mind 1) what if the type is not a sorcery object type? I guess it is just a string so could create a hashable key for those cases? </div>
</div></div></div></blockquote><div><br></div></div><div>Exactly.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div>2) the various format views need to be generic enough so we don't run into cases like "aor_summary_for_endpoint" view inside of the aor formatter</div></div></div></div></blockquote><div><br></div></div>
<div>
Yep, I wrote the CLI formatters with exactly that in mind, the summary output for aor is formatted exactly the same whether you ran 'pjsip list aors' or got the list as part of 'pjsip show endpoint'. The only difference is that the former lists all aors and the latter only lists the aors for the specific endpoint. From a user perspective it works out well because you're not getting 10 different views of aor depending on how you got to it.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 3) How does one object find another object that's in another module? For instance, how would the endpoint formatter look up the "endpoint identifier by ip" formatter to use as that object's id/key is not found in endpoint properties?</div>
</div></div></div></blockquote><div><br></div></div><div>In this case it's reverse bound. 'identify' objects have an 'endpoint' field that points back to the endpoint. So, if you have the endpoint, you can call ast_sorcery_retrieve_by_fields looking for all identify objects having an endpoint field naming the endpoint of interest. I created ast_sip_for_each_identify for just that purpose. Assuming that endpoint_identifier_ip registered its formatter, the for_each callback points to it.</div>
<div> </div></div></div></div></blockquote><br></div><div class="gmail_quote">Hmmm, if I understand correctly then you will have to have the endpoint_identifier_ip sorcery type name somewhere in the endpoint formatting code so it can look it up in the registered list. If that is the case that adds a burden on the developer where every new module that needs to format data along with the endpoint would need to modify that same section of code adding its lookup id/key (essentially a soft dependency if you will). Whereas the current way they just need to register with the endpoint formatter and the pjsip_configuration code is untouched.<br>
</div></div></div>
<br></blockquote><div>It would be nice if endpoint stored all its object relationships the same way but it doesn't. It stores its related aors as a comma separated string, its auths in 2 different auth arrays, channels you have to get through a snapshot, etc. Endpoint formatter code is going to have to be modified anyway because presumably if someone added a new module then endpoint would need to be modified to store the relationship. In the case of a reverse relationship like identify, it's 2 lines of code in endpoint formatter. One to look up the identify formatter and another to call ast_sip_for_each_identify. </div>
<div><br></div><div>What concerns me about lists is that they have to be traversed and tested for every call. It's flexible but it has overhead especially for high volume requests like the AMI. The hashtable does require some developer foreknowledge but I think the speed tradeoff is worth it.</div>
<div><br></div><div><br></div></div></div></div>