On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp <[email protected]> wrote:
> George Joseph wrote: > >> >> >> On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <[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. 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.
-- _____________________________________________________________________ -- 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
