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