[asterisk-dev] PJSIP CLI and AMI organization thoughts

[George Joseph]

On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell <kharwell at digium.com> wrote:

> On Fri, Dec 6, 2013 at 7:09 PM, George Joseph <george.joseph at fairview5.com
> > wrote:
>
>> On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell <kharwell at digium.com>wrote:
>>
>>> On Fri, 2013-12-06 at 14:21 -0700, George Joseph wrote:
>>>   <snip>
>>>
>>
>>> 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.
>>
>
> 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?
>

Exactly.


> 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
>

Yep, I wrote the CLI formatters with exactly that in mind, the summary
output for aor is formatted exactly the same whether you ran 'pjsip list
aors' or got the list as part of 'pjsip show endpoint'.  The only
difference is that the former lists all aors and the latter only lists the
aors for the specific endpoint.  From a user perspective it works out well
because you're not getting 10 different views of aor depending on how you
got to it.


> 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?
>

In this case it's reverse bound.  'identify' objects have an 'endpoint'
field that points back to the endpoint.  So, if you have the endpoint, you
can call ast_sorcery_retrieve_by_fields looking for all identify objects
having an endpoint field naming the endpoint of interest.  I created
ast_sip_for_each_identify for just that purpose.   Assuming that
endpoint_identifier_ip registered its formatter, the for_each callback
points to it.


>
>
>
>>
>>> <snip>
>>>
>>> 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.
>>
>>
>>
> Yeah then that makes sense to move it out if it is not object specific.
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131206/24c197c0/attachment.html>