<div dir="ltr"><div>My gut tells me no, mostly because if you're using the realtime interface, you're most likely inserting the records programatically (which I believe is your point).<br><br></div>Of course having functionality in one method and not another is always somewhat annoying, but in this case, I think the point of the wizard is to limit the amount of typing and complexities in setting up PJSIP right?<br><br>When you start getting into realtime, you're already into a more complicated abstraction layer, and the ability to understand the various components of your deployment are probably assumed.<br><br>Leif.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 7 October 2014 12:10, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank">george.joseph@fairview5.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""></span><span class=""></span><div class="gmail_quote"><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></blockquote></div><br>-- <br><div dir="ltr"><div>Leif Madsen<br>CoreUC Lead Systems Engineer<br></div>p: +1-613-800-7610<br><div><br></div></div>
</div></div></div></div>