Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote: snip It would be nice if endpoint stored all its object relationships the same way but it doesn't. It stores its related aors as a comma separated string, its auths in 2 different auth arrays, channels you have to get through a snapshot, etc. Endpoint formatter code is going to have to be modified anyway because presumably if someone added a new module then endpoint would need to be modified to store the relationship. In the case of a reverse relationship like identify, it's 2 lines of code in endpoint formatter. One to look up the identify formatter and another to call ast_sip_for_each_identify. auths, aors, and transports can also register with the endpoint formatting object so it shouldn't need to be modified. Also, if it did need to change for those particular cases I would be okay with since those are part of the res_pjsip api. The problem is identify (or some future module) is not part of the core res_pjsip api and is a loadable module. The api should not have to change for a loadable module. What concerns me about lists is that they have to be traversed and tested for every call. It's flexible but it has overhead especially for high volume requests like the AMI. The hashtable does require some developer foreknowledge but I think the speed tradeoff is worth it. I am not sure there would be a huge gain in performance as you still have to do the hash calculation and then a NULL check. Even so, unfortunately, I can't see away around this. -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Mon, Dec 9, 2013 at 8:49 AM, Kevin Harwell kharw...@digium.com wrote: On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote: snip It would be nice if endpoint stored all its object relationships the same way but it doesn't. It stores its related aors as a comma separated string, its auths in 2 different auth arrays, channels you have to get through a snapshot, etc. Endpoint formatter code is going to have to be modified anyway because presumably if someone added a new module then endpoint would need to be modified to store the relationship. In the case of a reverse relationship like identify, it's 2 lines of code in endpoint formatter. One to look up the identify formatter and another to call ast_sip_for_each_identify. auths, aors, and transports can also register with the endpoint formatting object so it shouldn't need to be modified. Also, if it did need to change for those particular cases I would be okay with since those are part of the res_pjsip api. The problem is identify (or some future module) is not part of the core res_pjsip api and is a loadable module. The api should not have to change for a loadable module. What concerns me about lists is that they have to be traversed and tested for every call. It's flexible but it has overhead especially for high volume requests like the AMI. The hashtable does require some developer foreknowledge but I think the speed tradeoff is worth it. I am not sure there would be a huge gain in performance as you still have to do the hash calculation and then a NULL check. Even so, unfortunately, I can't see away around this. If Asterisk were completely OO we could create object factories, interfaces and implementation classes that hide all of that. Unfortunately, it's not. Also unfortunately, the needs of human clients are different than system clients. Back to identify as the example... Even though endpoint doesn't have a pointer to the identify, the endpoint formatter still has to know about it specifically because it has to place its output in a consistent place relative to other objects. It can't just iterate through a list of formatters because the order could be different based on module load order. That'd be OK for a system client but not for a human client. -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Mon, 2013-12-09 at 09:17 -0700, George Joseph wrote: On Mon, Dec 9, 2013 at 8:49 AM, Kevin Harwell kharw...@digium.com wrote: On Sat, 2013-12-07 at 09:20 -0700, George Joseph wrote: snip It would be nice if endpoint stored all its object relationships the same way but it doesn't. It stores its related aors as a comma separated string, its auths in 2 different auth arrays, channels you have to get through a snapshot, etc. Endpoint formatter code is going to have to be modified anyway because presumably if someone added a new module then endpoint would need to be modified to store the relationship. In the case of a reverse relationship like identify, it's 2 lines of code in endpoint formatter. One to look up the identify formatter and another to call ast_sip_for_each_identify. auths, aors, and transports can also register with the endpoint formatting object so it shouldn't need to be modified. Also, if it did need to change for those particular cases I would be okay with since those are part of the res_pjsip api. The problem is identify (or some future module) is not part of the core res_pjsip api and is a loadable module. The api should not have to change for a loadable module. What concerns me about lists is that they have to be traversed and tested for every call. It's flexible but it has overhead especially for high volume requests like the AMI. The hashtable does require some developer foreknowledge but I think the speed tradeoff is worth it. I am not sure there would be a huge gain in performance as you still have to do the hash calculation and then a NULL check. Even so, unfortunately, I can't see away around this. If Asterisk were completely OO we could create object factories, interfaces and implementation classes that hide all of that. Unfortunately, it's not. Also unfortunately, the needs of human clients are different than system clients. Back to identify as the example... Even though endpoint doesn't have a pointer to the identify, the endpoint formatter still has to know about it specifically because it has to place its output in a consistent place relative to other objects. It can't just iterate through a list of formatters because the order could be different based on module load order. That'd be OK for a system client but not for a human client. This is true. With AMI the order doesn't matter, but I can see how it would with CLI stuff. Sounds like an ordered list of some sort is warranted. -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Mon, Dec 9, 2013 at 10:15 AM, Kevin Harwell kharw...@digium.com wrote: On Mon, 2013-12-09 at 09:17 -0700, George Joseph wrote: If Asterisk were completely OO we could create object factories, interfaces and implementation classes that hide all of that. Unfortunately, it's not. Also unfortunately, the needs of human clients are different than system clients. Back to identify as the example... Even though endpoint doesn't have a pointer to the identify, the endpoint formatter still has to know about it specifically because it has to place its output in a consistent place relative to other objects. It can't just iterate through a list of formatters because the order could be different based on module load order. That'd be OK for a system client but not for a human client. This is true. With AMI the order doesn't matter, but I can see how it would with CLI stuff. Sounds like an ordered list of some sort is warranted. Exactly, now who determines the order? I think it has to be the parent because the parent determines the context in which the children are displayed and the parent has to provide the child objects anyway. The children can't determine order relative to each other without knowing way more than they should. So, for the CLI I'll move to the registration scheme where objects register their handlers and the CLI processes the handlers top-down in a manner that provides deterministic and consistent ordering. -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, Dec 6, 2013 at 11:53 PM, Kevin Harwell kharw...@digium.com wrote: On Fri, Dec 6, 2013 at 11:27 PM, George Joseph george.jos...@fairview5.com wrote: On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell kharw...@digium.comwrote: On Fri, Dec 6, 2013 at 7:09 PM, George Joseph george.jos...@fairview5.com wrote: On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell kharw...@digium.comwrote: 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. It would be nice if endpoint stored all its object relationships the same way but it doesn't. It stores its related aors as a comma separated string, its auths in 2 different auth arrays, channels you have to get through a snapshot, etc. Endpoint formatter code is going to have to be modified anyway because presumably if someone added a new module then endpoint would need to be modified to store the relationship. In the case of a reverse relationship like identify, it's 2 lines of code in endpoint formatter. One to look up the identify formatter and another to call ast_sip_for_each_identify. What concerns me about lists is that they have to be traversed and tested for every call. It's flexible but it has overhead especially for high volume requests like the AMI. The hashtable does require some developer foreknowledge but I think the speed tradeoff is worth it. -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, 2013-12-06 at 14:21 -0700, George Joseph wrote: 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 think the models (summary/detail/some other view) are the same in all scenarios, but we are just approaching it from two different implementation perspectives. The way the code is currently structured removes the need for the flag, so there is no need for an if/switch statement. I already have a context object that maintains formatting flags, summary statistics, etc. that would be much different for AMI or ARI. Yes, the output between all could be quite different. For each object type there are a set of formatters, serializers, printers, or whatever we want to call them (for instance, to_string, to_json, to_xml, etc...). Typically when you want to print out a non-primitive property then it makes sense to call its formatter. However, in our case we have several different views depending on the output type, so we have to have custom formatters for each view. Currently we can register these custom formatters with the master object and when it gets formatted the associated object's custom formatter gets called (no need for a flag specifying the formatting view). Although now that I think about it having that flag would allow you to register multiple custom views for a [sub]type. That may actually be needed in some cases some I would be fine with adding that in. As far as breaking it out into separate lists (endpoints_to_json list, endpoints_to_cli list, aors_to_json, etc...) I don't see a need for it. It will add multiple/extra register functions and more looping when formatting/outputting. For instance, currently you register the [sub]type format function with a particular object type. If I am thinking about it correctly with separate lists you would essentially register the list with an object type and loop over the lists of lists to output the [sub]type custom view. 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. When it comes to file layout I am more of a fan of grouping functionality along with the object type. Personally I would rather see the ami commands for endpoints in with the endpoints and not group with ami commands for other types. That being said I'd be fine with for instance config_auth.c, config_auth_ami.c, config_auth_cli.c if one was so inclined. I'd also be fine with renaming pjsip_configuration to config_endpoint. Am I overthinking all of this? It's all perfectly clear in MY mind. :) I am quite sure I am :-) -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell kharw...@digium.com wrote: On Fri, 2013-12-06 at 14:21 -0700, George Joseph wrote: 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 think the models (summary/detail/some other view) are the same in all scenarios, but we are just approaching it from two different implementation perspectives. The way the code is currently structured removes the need for the flag, so there is no need for an if/switch statement. For the CLI, the only difference between summary and detail is that the detail flag causes the sorcery name/value pairs to be dumped in a tabular format. I already have a context object that maintains formatting flags, summary statistics, etc. that would be much different for AMI or ARI. Yes, the output between all could be quite different. For each object type there are a set of formatters, serializers, printers, or whatever we want to call them (for instance, to_string, to_json, to_xml, etc...). Typically when you want to print out a non-primitive property then it makes sense to call its formatter. However, in our case we have several different views depending on the output type, so we have to have custom formatters for each view. Currently we can register these custom formatters with the master object and when it gets formatted the associated object's custom formatter gets called (no need for a flag specifying the formatting view). Although now that I think about it having that flag would allow you to register multiple custom views for a [sub]type. That may actually be needed in some cases some I would be fine with adding that in. As far as breaking it out into separate lists (endpoints_to_json list, endpoints_to_cli list, aors_to_json, etc...) I don't see a need for it. It will add multiple/extra register functions and more looping when formatting/outputting. For instance, currently you register the [sub]type format function with a particular object type. If I am thinking about it correctly with separate lists you would essentially register the list with an object type and loop over the lists of lists to output the [sub]type custom view. 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. 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, Dec 6, 2013 at 7:09 PM, George Joseph george.jos...@fairview5.comwrote: On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell kharw...@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? 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 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? snip I wouldn't go down to config_auth_cli level. config_auth should have all auth related code whether CLI or AMI but there's CLI code at the pjsip level that's not object specific that should probably come out of pjsip_configuration and go in a pjsip_cli.c file. Yeah then that makes sense to move it out if it is not object specific. -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell kharw...@digium.com wrote: On Fri, Dec 6, 2013 at 7:09 PM, George Joseph george.jos...@fairview5.com wrote: On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell kharw...@digium.comwrote: 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. snip I wouldn't go down to config_auth_cli level. config_auth should have all auth related code whether CLI or AMI but there's CLI code at the pjsip level that's not object specific that should probably come out of pjsip_configuration and go in a pjsip_cli.c file. Yeah then that makes sense to move it out if it is not object specific. -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] PJSIP CLI and AMI organization thoughts
On Fri, Dec 6, 2013 at 11:27 PM, George Joseph george.jos...@fairview5.comwrote: On Fri, Dec 6, 2013 at 10:09 PM, Kevin Harwell kharw...@digium.comwrote: On Fri, Dec 6, 2013 at 7:09 PM, George Joseph george.jos...@fairview5.com wrote: On Fri, Dec 6, 2013 at 4:52 PM, Kevin Harwell kharw...@digium.comwrote: 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
