[asterisk-dev] PJSIP CLI and AMI organization thoughts

[Kevin Harwell]

On Fri, Dec 6, 2013 at 11:27 PM, George Joseph
<george.joseph at fairview5.com>wrote:

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

Hmmm, if I understand correctly then you will have to have the
endpoint_identifier_ip sorcery type name somewhere in the endpoint
formatting code so it can look it up in the registered list.  If that is
the case that adds a burden on the developer where every new module that
needs to format data along with the endpoint would need to modify that same
section of code adding its lookup id/key (essentially a soft dependency if
you will).  Whereas the current way they just need to register with the
endpoint formatter and the pjsip_configuration code is untouched.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131207/b6b3274f/attachment.html>