<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 7, 2014 at 8:37 AM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=mmichelson@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">mmichelson@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/07/2014 05:57 AM, Joshua Colp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm down with proposal #2 but I have to ask: would this work with realtime, and how?<br>
<br>
</blockquote>
<br></blockquote><div><br></div><div>If you're going through the trouble of setting up realtime I wonder if you would get any benefit from the config wizard approach.  Having said that, see below.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(In this response, I refer to the new configuration type as a "compound type" since I also refer to sorcery wizards, which are a different thing.)<br>
<br>
I'm thinking about it, and as long as compound types are restricted to read-only data, it could be made to work with realtime, but it would take some sorcery adjustments. The has_* options would have to be understood at the sorcery level, so that when sorcery is told "retrieve endpoint foo", sorcery can know to either retrieve the endpoint foo directly or through a compound type foo that has an endpoint. The realtime wizard would simply return the entire compound type, and the sorcery core would extract an endpoint from the returned data.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The other difficult part about realtime is that sorcery.conf relates sorcery types to entries in extconfig.conf. This means that you would likely want to have different "type=" for your different compound types so that each can be stored in different database tables. This takes away from the ease of just doing "type=wizard" that was proposed. You'd probably need to have a section in sorcery.conf to tell sorcery the names of types that are compound types. To illustrate, here's what I'm thinking:<br>
<br>
(sorcery.conf)<br>
[compound_types]<br>
types = phone,trunk<br>
<br>
or possibly ensure some level of type-safety by specifying what types the compound types are composed of:<br>
<br>
[compound_types]<br>
phone=endpoint,auth,aor<br>
<br>
(pjsip.conf)<br>
[my_phone]<br>
type=phone<br>
has_endpoint=yes<br>
has_aor=yes<br>
...<br>
<br>
When sorcery processes "my_phone", it sees type=phone and knows based on sorcery.conf that this is a compound type and can create individual objects based on the configuration it comes across.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Although the ast_sorcery_* API doesn't expose it, an object can be mapped to multiple wizards, right?  What if the compound object was stored in, and retrieved from,  one of the concrete wizards but the objects it creates are created in a memory wizard that's added to the object_type's wizards container. </div><div><br></div><div>Unfortunately, this doesn't address the real time aspect of realtime.  If you make a change to the backing compound object data store it's not automatically propagated to the created objects.   This brings be back to my question above...  If you're using realtime are you likely to even need the wizard approach.</div><div><br></div><div>I'm still thinking.</div><div><br></div></div></div></div>