On Tue, Oct 7, 2014 at 12:39 PM, George Joseph <[email protected]> wrote:
> 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. > As I'm thinking about it, maybe as a follow-on, a new realtime wizard that'd check the backing store and regenerate the base object on demand if the compound object changed. > > >> 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
