[asterisk-dev] PJSIP CLI and AMI organization thoughts

George Joseph george.joseph at fairview5.com
Fri Dec 6 15:21:05 CST 2013


This continues a conversation kharwell, mjordan and I were having on irc
this morning concerning the implementation of the cli output formatting.

Basically, I'm thinking that while we should absolutely re-use the
underlying plumbing ( we don't need 2 versions of ast_sip_for_each_contact,
for instance), the CLI and AMI are different enough that we shouldn't try
to re-use the formatter registration and execution plumbing.  The same
pattern maybe, but not share the structure definitions, list of formatters,
etc.

The pjsip/sorcery implementation is obviously a relational/oo model.
 Endpoint, Aor, Auth, etc are all first class objects with foreign
keys/references to each other.  Typically an API in this environment
doesn't de-normalize/de-reference/re-hydrate the references to other
objects.  In REST terms, if you do a GET on an endpoint, the response may
contain a collection of aor ids but you shouldn't be getting the detail for
each aor in an endpoint response.  If you want the details, you do a GET on
each aor.   A CLI implementation is much different.  If a human,
particularly this human, has to do a 'pjsip show endpoint', write down the
list of aors, then do a 'pjsip show aor' on each, the response from the
human would be quite vivid.  Also, aors being first-class objects in their
own right can be listed and details shown independently of any other object.

So, here's what I'm suggesting...
Two formatter registries, one for CLI and one for AMI.  I haven't been
following the ARI discussions at all so maybe there's a third?  Anyway,
this way the CLI or AMI command processors don't have to filter out the
ones they don't need and we don't unnecessarily lock the CLI and AMI
implementations together.  Each object implementation would register a
formatter for each mechanism which would take care of anything specific to
that mechanism.  For the CLI for instance, the formatter would provide a
human consumable summary or detail depending on a flag passed to it.  I
already have a context object that maintains formatting flags, summary
statistics, etc. that would be much different for AMI or ARI.

As a side note...  most of the cli stuff is in pjsip_configuration..c.  I'm
thinking of moving the common cli stuff into a new pjsip_cli.c and the
formatters into their respective objects and since pjsip_configuration.c
really only manages endpoint, renaming it to config_endpoint.c.  A
pjsip_ami.c might be in order as well for common pjsip cli stuff.

Am I overthinking all of this? It's all perfectly clear in MY mind. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131206/27d577bd/attachment.html>


More information about the asterisk-dev mailing list