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

[Johansson Olle E]

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

>
>
>> +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.  :-)
Ouch. Let's start with events if that's the case.


>> +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?
And we also have systemname, which is easier to handle by
humans... Yes, I saw what you did in the ais code.
I thought that entity ID was only used in AIS, not internally in
Asterisk.

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

Absolutely. I only have README-ware at this point. Where's his docs? :-)

/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/193483ae/attachment-0001.bin