[asterisk-dev] manager event conversion strategy

Brian Degenhardt bmd at digium.com
Tue Feb 10 13:54:36 CST 2009


Johansson Olle E wrote:
> 10 feb 2009 kl. 18.00 skrev Russell Bryant:
> 
>>
>> On Feb 10, 2009, at 10:46 AM, Johansson Olle E wrote:
>>
>>>> I guess my main concern is that I don't want to compromise quality  
>>>> of
>>>> the new interface for the sake of making it exactly backwards
>>>> compatible with manager 1.1.  Given the work that was done to  
>>>> improve
>>>> consistency in manager 1.1, It may not be an issue.  We'll see!
>>
>>>>
>>> Well, the result may very well be manager 1.2 with some small
>>> changes for a few bugs that we find... Let's try to avoid that
>>> and take the challenge. :-)
>>
>>
>> That works for me.
>>
>> Another thing to note is that we are going to end up with a lot of
>> additional events in the new interface that were not in manager 1.1.
>> The new CEL system is based on the event framework, and in that patch,
>> a lot of new events have been added.  Some of those events may already
>> be pretty much the same as a manager event right next to it.  So, we
>> should consider what is in that branch for this project as well to
>> help reduce what work we have to do.
> 
> Absolutely. Maybe we should prematurely add the CEL-version of the  
> event header files
> to trunk so that both branches can work on the same header files?

CEL is in reviewboard very close to being committed AFAIK.
One thing to note though is that CEL events require a bunch of stuff in
the channel structure to be passed with them (context name, priority,
extension, caller-id, etc.)  I'm not overjoyed with how these all are
mandatory IEs, but there's not really a way in events of presenting a
menu of extra metadata and letting event subscribers requests the pieces
they want, so you just dump everything into each event.

-bmd



More information about the asterisk-dev mailing list