George Joseph wrote:
On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp <[email protected] <mailto:[email protected]>> wrote:George Joseph wrote: On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: George Joseph wrote: <snip> What if contacts are stored in an external database? Your proposal would also have them going there as well. This would require an explanation for deployers to know what is going on exactly and what they are. As well this means there would be a period of time where the permanent contacts would not be present if other instances are sharing the same database and one restarts. They can't be today can they? The dynamic ones are explicitly mapped to astdb and the permanent ones are explicitly placed in the aor based container. Can you even use sorcery.conf to map contacts somewhere else given that they're just strings in an aor? You sure can. Who would even know they can do that besides you? :) I believe there's a wiki page which details using PJSIP with realtime, and there's also the table in alembic. In general there is. There aren't any specific instructions for contacts though. Permanent contacts specifically. The ERD on the wiki shows contact but pjsip.conf.sample only mentions contacts in the context of aors. There's no object mentioned. If we took a poll, how many people would respond that they know they could define permanent contacts in realtime as separate objects. :) I was referring to dynamic contacts added externally by registration. <snip> So. This is what I was originally trying to express when you did the wizard work, you've just gone about it in a different manner. I think this is a rather specialized addition that could be done in a better way. Right now sorcery wizards can't be programmatically added. They just can't. You have to do it from the sorcery.conf configuration file. Not true. ast_sorcery_apply_wizard_mapping allows yo to add a wizard to any object type at run time. That's what the config_wizard does. When the object type registers, it adds a memory wizard to the object type's wizard list. The config wizard then manipulates the memory wizard. It adds a wizard but does not return a handle to it. It also doesn't allow you to specify where to place it. It's always at the end. You don't need a handle, you have the wizard itself. Correct on the order. How? What I'm talking about is something like: You can get the wizard as a result of the wizard_mapped observer. That's an indirect mechanism, and may not order things as expected unless you force it. int res; struct ast_sorcery_wizard *wizard; void *data; res = ast_sorcery_apply_explicit_wizard(sorcery, "endpoint", "memory", "", &wizard, &data); That function would explicit at a wizard to the front, and return the specific wizard interface and instance. Instant access to manipulate that specific instance with the CRUD interface and a guarantee of its position. Agreed and that's easy enough. I'm not sure it helps any though. It helps you be able to inject a wizard at the front and have direct access to manipulate it - without going through the normal wizards applicable to the object type itself. <snip> From who's perspective though? "I'm implementing qualify/contact status support. I need to store X information and keep it around only for the lifetime of Asterisk. I need to know when Y happens. I need to be able to get Z information." The entire reason I'm asking for such a basic definition of what the functionality needs is because things keep growing and growing, and we keep running into things. We need to step back and look at what the functionality is trying to achieve and how best it can be done over all. Perhaps without even involving sorcery. Without this basic definition and (I hesitate to use the words) use cases we may make this into an even bigger thing when a simple solution would have been the best one all along. True but we also risk a point solution that's not good for anything else. How about this, let me start with a patch that adds the wizard mods. Maybe "ast_sorcery_insert_wizard" that looks like your prototype with a parameter for order. WIZARD_FIRST, WIZARD_LAST or something.
I think that would be a fine addition.
Then let me propose how I'd use it to create a wizard specifically for contacts. Then we can decide if it could be generalized for other use or left specifically for contacts.
Sure, but without an actual idea of what problem is trying to be solved or how things will be improved - it's hard to say if that's the right solution.
-- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- 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
