<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">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 class="h5">On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell <span dir="ltr"><<a href="mailto:kharwell@digium.com" target="_blank">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 class="im"><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? 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 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>
<br><div> </div><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 class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div>
<snip><br><div>
<br></div></blockquote></div><div>I wouldn't go down to config_auth_cli level.  config_auth should have all auth related code whether CLI or AMI but there's CLI code at the pjsip level that's not object specific that should probably come out of pjsip_configuration and go in a pjsip_cli.c file.  </div>
<div class="im">
<div> </div><br></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">Yeah then that makes sense to move it out if it is not object specific.<br></div></div>