[asterisk-dev] manager event conversion strategy

[Mark Michelson]

Johansson Olle E wrote:
> 
> 10 feb 2009 kl. 17.15 skrev Russell Bryant:
> 
>>
>> On Feb 10, 2009, at 9:53 AM, Johansson Olle E wrote:
>>
>>> Well, I wanted to avoid that. The idea was to first make sure that
>>> we could produce the same result on the manager interface,
>>> not change any syntax at all in Manager 1.1 because of this change.
>>>
>>>> From a performance point of view, it would be very easy to add a
>>>> compiler flag which turns the calls of manager_event() into nothing
>>>> if
>>>> you don't want support for the old system.  However, keeping the code
>>>> there means we can keep the old code around for backwards
>>>> compatibility purposes for some period of time.
>>> I think you assume that we can't produce compatible output on the
>>> manager connection...
>>
>> You're right.  I would be happy to be proven wrong, though!
>>
>> 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. :-)
> 
>>
>>
>>>> I would also like to point out that there is already a branch in
>>>> team/
>>>> group called "manager2" that was started by Mark Michelson for this
>>>> same project.  We should sync up with him on what work he has in
>>>> there
>>>> so that we're all working together toward a common goal.
>>>
>>> Absolutely. I only have README-ware at this point. Where's his
>>> docs? :-)
>>
>>
>> The docs are probably in his brain.  :-)  I'm sure he'll speak up
>> shortly ...
> 
> Hmm. Did you install the neural interface when Digium employed him?
> I can't find his brain on the Digium Dundi link so I can dump it...
> 

Sorry, my brain wasn't on the network until just now :)

 From what I'm reading, the goal of this project, or at least the beginning of 
it, is exactly the same as manager2. manager2 works by changing the 
manager_event calls to send an internal Asterisk event, which is subscribed to 
by the manager2 modules to generate text expected by various types of manager 
sessions. For now, I had just written res_manager2.c, which converts the 
subscribed events into the format that you would typically see for text-based 
connections on port 5038. The plan was also to eventually create a res module 
for the other manager connection types so that they may subscribe to the events 
and generate what that particular type of manager connection expects to see.

As far as the current status of the manager2 code, the actual res_manager2.c 
code is a bit of a mess, but it appears to work correctly for my simple telnet 
sessions on port 5038. At this point, the only Asterisk module where I converted 
the manager_event calls was app_queue.c. One improvement that was on the horizon 
for res_manager2.c was to convert it to use a taskprocessor instead of using its 
current manual setup of queuing messages to another thread. In addition, the 
common code that would be used by all the manager2 res modules should be moved 
to the core.

As another major part of manager2, which I had just started before I stopped 
working on the branch, I was going to allow for more fine-tuned event 
subscriptions for manager users. Since the Asterisk event system allows for 
subscribing to specific event types that contain certain IE values, it seems 
like it would not be especially difficult to pass this level of control to the 
user so that he may see only specific events under specific circumstances.

There are two main reasons why I have not been actively developing in the 
manager2 branch

1) Much more important issues have come up, leaving this low on my priority list.
2) There was potential for overlap between the manager2 branch and CEL. I was 
waiting for CEL work to be complete (i.e. merged into trunk) before I continued 
further.

Quite frankly, it's been quite a long time since I even looked at the manager2 
code, I hadn't spent a great deal of time on it, and I was sort of flying by the 
seat of my pants on it. I would not be opposed if you guys wanted to start up 
new development along the same lines.

Mark Michelson