[asterisk-dev] Google Summer of Code 2009

[Russell Bryant]

Mark Michelson wrote:
> I think that project 1f should be re-worded. The main problem I see is that I 
> don't think the distinction between the new event system and the pre-existing 
> manager events is made clear enough at the opening. It can be determined from 
> context clues that this is the case, but I think defining the project more 
> clearly would make a student potentially more interested in it.
> 
> While I am not going to direct you on how you should word the project, I will 
> provide an alternate description here. Feel free to use it, modify it to your 
> liking, or ignore it.
> 
> f) Asterisk has a relatively new generic asynchronous event API. While it has 
> been implemented in several areas of the code base, one place where it has not 
> been utilized but would make a great fit would be to replace the legacy code 
> used for generating events on the Asterisk Manager Interface (AMI). This project 
> would entail creating an interface to handle these generic events on behalf of 
> the AMI as well as converting existing AMI events to the newer method of event 
> generation.
> 
> Actually, upon reading my description, I've noticed that I may have actually 
> added something that is not intended to be part of the project. Does the project 
>   just involve conversion of manager events to generic ones or does it also 
> involve writing a subscriber for these events so that when a manager event is 
> fired that the contents of the event can be converted to the proper format and 
> sent to logged-in managers?

Thanks for the feedback, Mark.  I can certainly see your point that I 
didn't make that project clear enough.

I think you can probably think of this project in a couple of phases. 
There is the addition of ast_events in places that currently have a 
manager_event().  I think that is the first phase.  Beyond that, things 
get a little bit less defined as to what the "right" next step is.

At that point, you could write a completely new socket interface that 
exposed the event API.  You could also attempt to update the existing 
manager interface to use the new event framework for handling the events 
that are sent out.  I personally have some doubts regarding updating the 
existing manager interface to use the ast_event API without breaking 
backwards compatibility or sacrificing quality of events for the sake of 
AMI compatibility.  However, I'm certainly open to someone trying to see 
  what they can come up with.

I'll update the text in the document to address your feedback, and 
include some of my own comments, as well.

-- 
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org