[asterisk-dev] PJSIP CLI and AMI organization thoughts

[Kevin Harwell]

On Mon, 2013-12-09 at 09:17 -0700, George Joseph wrote:
> 
> On Mon, Dec 9, 2013 at 8:49 AM, Kevin Harwell <kharwell at 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.
>         

>