[asterisk-dev] PJSIP Configuration Wizard (Was: Opinions Needed: PJSIP Outboud Registration with multiple server_uris)

[George Joseph]

On Tue, Oct 7, 2014 at 12:39 PM, George Joseph <george.joseph at fairview5.com>
wrote:

> On Tue, Oct 7, 2014 at 11:56 AM, Leif Madsen <lmadsen at thinkingphones.com>
> 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 <george.joseph at fairview5.com>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141007/c773e66e/attachment-0001.html>