[asterisk-dev] manager event conversion strategy (was: oej: branch oej/managergames r174538 - /team/oej/managergames/)

[Russell Bryant]

Hey!  Thanks for your interest in this project.  I have some thoughts  
which I will include below.

On Feb 10, 2009, at 5:44 AM, SVN commits to the Digium repositories  
wrote:

> +Manager conversion to the new event structure
> +---------------------------------------------
> +
> +The manager events generated by Asterisk modules today basically  
> produce a simple
> +string and send that to the manager module for handling.
> +
> +I would like to start the conversion to a new *INTERNAL* format by  
> adding a new
> +manager event call that uses a new structure and support in  
> manager.c for
> +converting this to the existing format at transmission to manager  
> port or http server.


I suggest that the plan should be that this conversion be done along  
side the existing manager code.  Essentially, this means that there  
will be ast_event code right next to a call to manager_event().  This  
will allow us to keep the old code around while we work on the new  
system.

 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.

> +When we have this working, we can convert existing modules to the  
> new format and
> +start looking at actions/responses, propably starting with the  
> outbound responses.

The event system is not going to be applicable to the actions/ 
responses part of the manager interface today.  That is going to  
require a new piece of infrastructure to be build.  The event API will  
only handle the asynchronous event parts of the current manager  
interface.

I have some ideas for that part of it, as well, but we should treat it  
as a separate project, I think.  It all falls under the high level  
"pinemango" umbrella.  :-)

> +This will require:
> +
> +- A review of the event data structures
> +	- Do we have the data types we need?
> +	- Example: Do we need a definition for host adress - IP or name?

I think IP address would be a good data type.  I had not yet made any  
events that needed it.

> +
> +- A review of the event data values - which are string, which are  
> numeric, which are something else?
> +
> +After discussion with Russell at Fosdem 2009, I don't believe that  
> this will
> +be a huge process. We will need help from the community by applying  
> this as a janitor process,
> +and I'm sure we'll get the help we need provided we have proper  
> guidelines.
> +
> +I am also considering adding data types for the various event  
> headers. This is for
> +the possibility of sharing events across the event bus to other  
> systems.
> +The event structure will need an addition of the system name/ 
> eventID for the remote
> +system, so we can separate incoming events from local events.

Events already automatically have an entity ID added to them  
automatically by the event core.  This was needed for sharing events  
between servers.  The entitiy ID looks just like it does for DUNDi.   
It's a unique identifier, in the same form as a MAC address.  When  
Asterisk starts, we try to grab one from a network interface, or it  
can be configured in asterisk.conf.  Does this handle what you had in  
mind?

> +This will take some time, as I only can work on this in spare time.  
> Any assistance
> +is of course welcome and feedback is gently asked for!

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.

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