On Tue, Oct 7, 2014 at 11:56 AM, Leif Madsen <[email protected]> wrote:
> 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). > > 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? > > 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. > Exactly on all points. If I use the approach I outlined below, you could still use a realtime backing store to house the compound objects. You'd just have to issue a reload to get to get it to take effect if you change it. I think that's a reasonable limitation for an initial release given the above. > Leif. > > On 7 October 2014 12:10, George Joseph <[email protected]> > wrote: > >> 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. >> >> 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. >> >> I'm still thinking. >> >> > -- > Leif Madsen > CoreUC Lead Systems Engineer > p: +1-613-800-7610 > > > -- > _____________________________________________________________________ > -- 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 >
-- _____________________________________________________________________ -- 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
