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

[Matthew Jordan]

On Wed, Dec 4, 2013 at 3:53 PM, David M. Lee <dlee at digium.com> wrote:

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

Information that ties events together is fine. However, as a user of the
system, I would expect that the unique ID of the "thing" - whatever it is -
is the only unique ID that either (a) I need to provide or (b) is provided
to me by the system. Having two unique IDs - one that is returned by the
system that acts as a handle to the resource and another user provided one
to tie the responses back to the events feels wrong.

>From a client perspective, it's more stuff to track and more things you
have to use to tie things together. That's annoying and increases the
processing burden on the client.

>From a server implementation perspective - depending on the implementation
- you can constrain your system if you require channels to have added
metadata to function properly (from the client perspective). Each variable
set requires a channel lookup in the channels container, which locks that
container. If you're originating a lot of calls simultaneously, you're
throwing a lot of extra locking into the mix that shouldn't strictly be
necessary.

Furthermore, if you allow a client to supply the unique ID, you run into a
lot of side issues we've historically not had to worry about, since the
unique ID was generated by Asterisk. Maximum field lengths, implicit
knowledge that the ID was created with the object, etc. These can all be
worked around, but we'd still have to go through and work through all of
the assumptions consumers of objects make about the type/nature of the
various object's unique IDs.



>
> 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 can see that. Which adds credence to having the user supply the unique ID
of the thing. I do think that channels are the most likely culprit of this
problem - although as Matt DiMeo pointed out in another thread, this
happens with playbacks as well.

For everything but channel unique IDs having a user supply the unique ID
could possible work - the fact that channel unique IDs have historically
been more than just a random number is what complicates the picture.
There's probably a path forward to fixing linked ID propagation, as the
rules for propagating the linked ID are based on channel creation time
which can be extracted from another field - but people have always relied
on the channel unique ID being a timestamp for a lot of things. There's a
laundry list of e-mails on the -dev/-user lists where people have shown
dialplans extracting the channel unique ID (or AMI/AGI scripts) to
determine when the channel was created. We'll break a lot of people if we
break that scheme - and if we allow a user to supply the ID, we've
implicitly broken that scheme.

There's also the inevitable errors that will occur if someone supplies the
same identifier twice. Hilarity will definitely ensue.


>
> 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.
>
>
I think we need to aim for those situations. The days of someone using
Asterisk in a simple synchronous environment are pretty long behind us.

-- 
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-app-dev/attachments/20131205/0268e18e/attachment.html>