<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Joseph wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a><br>
<mailto:<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>>> wrote:<br>
<br>
George Joseph wrote:<br>
<br>
<snip><br>
<br>
<br>
<br>
What if contacts are stored in an external<br>
database? Your<br>
proposal<br>
would also have them going there as well. This<br>
would require an<br>
explanation for deployers to know what is going on<br>
exactly<br>
and what<br>
they are. As well this means there would be a<br>
period of<br>
time where<br>
the permanent contacts would not be present if other<br>
instances are<br>
sharing the same database and one restarts.<br>
<br>
<br>
They can't be today can they? The dynamic ones are<br>
explicitly<br>
mapped to<br>
astdb and the permanent ones are explicitly placed in<br>
the aor based<br>
container. Can you even use sorcery.conf to map contacts<br>
somewhere else<br>
given that they're just strings in an aor?<br>
<br>
<br>
You sure can.<br>
<br>
<br>
Who would even know they can do that besides you? :)<br>
<br>
<br>
I believe there's a wiki page which details using PJSIP with<br>
realtime, and there's also the table in alembic.<br>
<br>
<br>
In general there is. There aren't any specific instructions for<br>
contacts though. Permanent contacts specifically. The ERD on the wiki<br>
shows contact but pjsip.conf.sample only mentions contacts in the<br>
context of aors. There's no object mentioned. If we took a poll, how<br>
many people would respond that they know they could define permanent<br>
contacts in realtime as separate objects. :)<br>
</blockquote>
<br>
I was referring to dynamic contacts added externally by registration.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<snip><br>
<br>
So. This is what I was originally trying to<br>
express when<br>
you did the<br>
wizard work, you've just gone about it in a<br>
different manner. I<br>
think this is a rather specialized addition that<br>
could be<br>
done in a<br>
better way.<br>
<br>
Right now sorcery wizards can't be<br>
programmatically added.<br>
They just<br>
can't. You have to do it from the sorcery.conf<br>
configuration file.<br>
<br>
<br>
Not true. ast_sorcery_apply_wizard_mapping allows yo<br>
to add a<br>
wizard to<br>
any object type at run time. That's what the config_wizard<br>
does. When<br>
the object type registers, it adds a memory wizard to<br>
the object<br>
type's<br>
wizard list. The config wizard then manipulates the<br>
memory wizard.<br>
<br>
<br>
It adds a wizard but does not return a handle to it. It<br>
also doesn't<br>
allow you to specify where to place it. It's always at the end.<br>
<br>
<br>
You don't need a handle, you have the wizard itself. Correct on<br>
the order.<br>
<br>
<br>
How? What I'm talking about is something like:<br>
<br>
<br>
You can get the wizard as a result of the wizard_mapped observer.<br>
</blockquote>
<br>
That's an indirect mechanism, and may not order things as expected unless you force it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
int res;<br>
struct ast_sorcery_wizard *wizard;<br>
void *data;<br>
res = ast_sorcery_apply_explicit_wizard(sorcery, "endpoint",<br>
"memory", "", &wizard, &data);<br>
<br>
That function would explicit at a wizard to the front, and return<br>
the specific wizard interface and instance. Instant access to<br>
manipulate that specific instance with the CRUD interface and a<br>
guarantee of its position.<br>
<br>
<br>
Agreed and that's easy enough. I'm not sure it helps any though.<br>
</blockquote>
<br>
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.<br>
<br>
<snip><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
From who's perspective though?<br>
</blockquote>
<br>
"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."<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></blockquote><div><br></div><div>True but we also risk a point solution that's not good for anything else.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>