[asterisk-app-dev] Originate/Channel Creation as a two step process

[David M. Lee]

On Dec 4, 2013, at 3:08 PM, Matthew Jordan <mjordan at digium.com> wrote:

> 
> On Wed, Dec 4, 2013 at 2:56 PM, David M. Lee <dlee at digium.com> wrote:
> 
> Let’s be consistent and create a ChannelOriginated event. We can guarantee that this will be the first event for originated channels. It will have the appArgs and channel information, similar to the StasisStart event. The application can put a unique identifier in the application’s arguments in order to associate the originated channel with a request.
> 
> This is basically what we have today, where you specify a UUID through a channel variable and then look for that identifier in subsequent events. This feels like a hack, not a solution.

That depends on your point of view. Complicating the process of origination for these sorts of event ordering issues feels like more of a hack to me. Adding events and information to events to aid in coordination feels more natural.

Giving it some thought, this problem may be more pervasive than we realized. You can get the same response/event ordering issues with playbacks and recordings. Going forward, any resource that 1) can be created via ARI and 2) has events associated with it could run into this same problem. If we follow this same pattern, then much of the API will be broken down into two-stage create/do-it invocations. Which *really* feels wrong to me.

I think to come up with the correct solution we’ll have to think about how the API will be used by different programming environments.

There’s simple synchronous environments. In these environments, you actually don’t have a problem. In these environments, HTTP clients only offer synchronous interfaces that block until a response is received. You wouldn’t process any received events on the WebSocket until you’re done processing the response to your HTTP request. This works great for small, simple applications. But it won’t scale.

To scale, you need to build an asynchronous/event driven application (Node.js, Twisted, Akka, etc.). In these environments, you already have to deal with the asynchronous coordination of events. Because it’s such a part of problem of building these applications, the frameworks give you tools to help deal with coordination problems (futures, promises, deferrers, etc.).

What worries me will be the in-between land of multi-threaded applications. If you have one thread processing the WebSocket, and ARI invocations happening on a different thread, you’ll definitely find yourself in the land of things happening on one thread before you expect them to. And the frameworks aren’t very helpful in dealing with this, either.

So, stuff to think about. There’s not an obviously right solution that jumps out at me, though.

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131204/f4f7d29e/attachment-0001.html>