<div dir="ltr">This continues a conversation kharwell, mjordan and I were having on irc this morning concerning the implementation of the cli output formatting.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So, here's what I'm suggesting...</div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>Am I overthinking all of this? It's all perfectly clear in MY mind. :)</div><div><br></div><div><br></div></div>