On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote: > <snip> > 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. > auths, aors, and transports can also register with the endpoint formatting object so it shouldn't need to be modified. Also, if it did need to change for those particular cases I would be okay with since those are part of the res_pjsip api.
The problem is identify (or some future module) is not part of the core res_pjsip api and is a loadable module. The api should not have to change for a loadable module. > 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. > I am not sure there would be a huge gain in performance as you still have to do the hash calculation and then a NULL check. Even so, unfortunately, I can't see away around this. > > -- _____________________________________________________________________ -- 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
