[asterisk-dev] Questions about sorcery.

[Matthew Jordan]

On Thu, Jun 20, 2013 at 5:20 PM, Joshua Colp <jcolp at digium.com> wrote:

> Ron Arts wrote:
>
>> So how would I set that res_sip used my sorcery module 'fuzzbox'?
>> Like this?
>>
>
> To delegate "endpoint" types to fuzzbox:
>
> [res_sip]
> endpoint=fuzzbox
>
>
>  And would I need to issue a reload command, or would it work on a
>> 'dynamic realtime' basis,
>> and it would have some 'check and refetch if changed' mechanism?
>>
>
> It queries the configured wizards, it's up to them to do whatever. If you
> are caching then it will query the cache first. If you need immediate
> changes then you have to make your own caching wizard or cache within your
> module and invalidate when it's out of date.
>
>
If you get *really* interested in playing around with things...

There are a number of frameworks that made their way into Asterisk 12 as a
result of the challenges we found ourselves facing. Two of the big ones are:
* Stasis - an internal message pub/sub message bus that conveys the state
of the most important objects throughout Asterisk
* Sorcery - a CRUD-ish data abstraction layer that lets you mask away real
time/conf file parsing/AstDB access/wherever else you want to get your data

One of the really cool things about Stasis is that - for the primary
telephony objects in Asterisk (bridges, channels, device state, etc.) - it
caches the last known state in an internal cache. Consumers can subscribe
for updates; they can also query the cache for the last known value.
Currently, all of this is internal, and the cache is rather simple - an in
memory container of the objects.

Sorcery lets you push your run-time objects out to whatever you specify (if
you have a wizard for it). It can also update objects.

Now, this is where it gets really interesting.

Technically, with a bit of effort, you could forward Stasis's primary
caches to a secondary cache that was created with Sorcery. (And no, we
haven't done this yet - partially because we didn't need to use Sorcery in
Stasis, and partially because we've been wanting to keep Stasis as fast as
possible. Forwarding things from one cache to another should be relatively
fast however) Now you can persist all of the run-time objects in whatever
you want - the AstDB - or a MySQL database. Your channel state, bridge
state, device state, etc. can all be cached in a hierarchy, going all the
way out to an external system.

Going the other direction - re-creation of state within Asterisk from an
external system - would be a monumental amount of effort. However, I
suspect that simply having Asterisk's state readily available for the
perusing would open up a lot of interesting applications for people
building systems with Asterisk.

I suspect we're going to have lots of fun things to build on top of
Asterisk 12.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130620/316b0778/attachment.htm>