On Fri, Dec 6, 2013 at 11:27 PM, George Joseph <[email protected]>wrote:
> > On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell <[email protected]>wrote: > >> On Fri, Dec 6, 2013 at 7:09 PM, George Joseph < >> [email protected]> wrote: >> >>> On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell <[email protected]>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.
-- _____________________________________________________________________ -- 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
