[asterisk-dev] manager event conversion strategy

[Johansson Olle E]

10 feb 2009 kl. 18.47 skrev 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.

Thanks for the braindump. I'll take a look at your mess, wasn't aware  
of that work.

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2206 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090210/cff4b9f8/attachment.bin