<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 5:23 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">
On Thu, Apr 30, 2015 at 5:06 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>
<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>><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> <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.<br>
This<br>
would require an<br>
explanation for deployers to know what is<br>
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<br>
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<br>
ones are<br>
explicitly<br>
mapped to<br>
astdb and the permanent ones are explicitly<br>
placed in<br>
the aor based<br>
container. Can you even use sorcery.conf to<br>
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<br>
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<br>
poll, how<br>
many people would respond that they know they could define permanent<br>
contacts in realtime as separate objects. :)<br>
<br>
<br>
I was referring to dynamic contacts added externally by registration.<br>
<br>
<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<br>
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<br>
sorcery.conf<br>
configuration file.<br>
<br>
<br>
Not true. ast_sorcery_apply_wizard_mapping<br>
allows yo<br>
to add a<br>
wizard to<br>
any object type at run time. That's what the<br>
config_wizard<br>
does. When<br>
the object type registers, it adds a memory<br>
wizard to<br>
the object<br>
type's<br>
wizard list. The config wizard then<br>
manipulates the<br>
memory wizard.<br>
<br>
<br>
It adds a wizard but does not return a handle to<br>
it. It<br>
also doesn't<br>
allow you to specify where to place it. It's<br>
always at the end.<br>
<br>
<br>
You don't need a handle, you have the wizard itself.<br>
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>
<br>
<br>
That's an indirect mechanism, and may not order things as expected<br>
unless you force it.<br>
<br>
<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<br>
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>
<br>
<br>
It helps you be able to inject a wizard at the front and have direct<br>
access to manipulate it - without going through the normal wizards<br>
applicable to the object type itself.<br>
<br>
<snip><br>
<br>
<br>
<br>
From who's perspective though?<br>
<br>
<br>
"I'm implementing qualify/contact status support. I need to store X<br>
information and keep it around only for the lifetime of Asterisk. I<br>
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<br>
functionality needs is because things keep growing and growing, and<br>
we keep running into things. We need to step back and look at what<br>
the functionality is trying to achieve and how best it can be done<br>
over all. Perhaps without even involving sorcery. Without this basic<br>
definition and (I hesitate to use the words) use cases we may make<br>
this into an even bigger thing when a simple solution would have<br>
been the best one all along.<br>
<br>
<br>
True but we also risk a point solution that's not good for anything else.<br>
<br>
How about this, let me start with a patch that adds the wizard mods.<br>
Maybe "ast_sorcery_insert_wizard" that looks like your prototype with a<br>
parameter for order. WIZARD_FIRST, WIZARD_LAST or something.<br>
</blockquote>
<br>
I think that would be a fine addition.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then let me propose how I'd use it to create a wizard specifically for<br>
contacts. Then we can decide if it could be generalized for other use<br>
or left specifically for contacts.<br>
</blockquote>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Understood, but I'll outline that with the proposal.</div><div><br></div></div></div></div>