[asterisk-dev] Questions about sorcery.

[Ron Arts]

> 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.
>

So basically AMI on steroids. But I would be concerned about performance.
If asterisk is heavily loaded internal state changes happen really
often, and pushing
these out will cost you even more CPU and system load. Being able to
query the cache
would only be interesting to re-sync state after a problem, because
normally you can
subscribe to changes anyway. It would be interesting to be able to subscribe
to stasis externally, but that's what probably stasis-http is for?
By the way, this may be after the fact, but is there a specific reason
for choosing
long-poll http over other message queue protocols like zeromq, or mqtt?

I'm sorry if I'm rambling or keeping you from more useful work...

Ron