<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 8:49 AM, 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote:<br>

><br>
<snip><br>
<br>
> It would be nice if endpoint stored all its object relationships the<br>
> same way but it doesn't. It stores its related aors as a comma<br>
> separated string, its auths in 2 different auth arrays, channels you<br>
> have to get through a snapshot, etc.  Endpoint formatter code is going<br>
> to have to be modified anyway because presumably if someone added a<br>
> new module then endpoint would need to be modified to store the<br>
> relationship.  In the case of a reverse relationship like identify,<br>
> it's 2 lines of code in endpoint formatter.  One to look up the<br>
> identify formatter and another to call ast_sip_for_each_identify.<br>
><br>
auths, aors, and transports can also register with the endpoint<br>
formatting object so it shouldn't need to be modified.  Also, if it did<br>
need to change for those particular cases I would be okay with since<br>
those are part of the res_pjsip api.<br>
<br>
The problem is identify (or some future module) is not part of the core<br>
res_pjsip api and is a loadable module.  The api should not have to<br>
change for a loadable module.<br></blockquote><div><br></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">
> What concerns me about lists is that they have to be traversed and<br>
> tested for every call.  It's flexible but it has overhead especially<br>
> for high volume requests like the AMI. The hashtable does require some<br>
> developer foreknowledge but I think the speed tradeoff is worth it.<br>
><br>
I am not sure there would be a huge gain in performance as you still<br>
have to do the hash calculation and then a NULL check.  Even so,<br>
unfortunately, I can't see away around this.<br>
><br>
><br></blockquote><div>If Asterisk were completely OO we could create object factories, interfaces and implementation classes that hide all of that.  Unfortunately, it's not.   Also unfortunately, the needs of human clients are different than system clients.   Back to identify as the example...  Even though endpoint doesn't have a pointer to the identify, the endpoint formatter still has to know about it specifically because it has to place its output in a consistent place relative to other objects.  It can't just iterate through a list of formatters because the order could be different based on module load order.   That'd be OK for a system client but not for a human client.</div>
<div><br></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><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">

<span class=""><font color="#888888"><br>
<br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</font></span></blockquote></div><br></div></div>