On Mon, 2013-12-09 at 09:17 -0700, George Joseph wrote: > > On Mon, Dec 9, 2013 at 8:49 AM, Kevin Harwell <kharw...@digium.com> > wrote: > 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. > > > > >
> 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. This is true. With AMI the order doesn't matter, but I can see how it would with CLI stuff. Sounds like an ordered list of some sort is warranted. > > -- _____________________________________________________________________ -- 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