Parse asterisk's "core-en_US.xml" file to get all the manager function + parameter definitions

[dkgroot]

How about using the /var/lib/asterisk/documentation/core-en_US.xml file which the asterisk make process generates automatically since asterisk-1.8. It will provide you with all the manager functions for that asterisk version including the parameter it accept. After parsing it once, you only have to verify if the timestamp on that files has changed. It should make 90-95% available and only require manual intervention for some quirky Message and the few external channel drivers like chan-sccp-b chan-dongle chan-lcr etc. If you like you could persuade them to produce a similar file (i would be willing to do this for the chan-sccp-b project would if so requested).

The content of that files looks like:

        <manager name="MixMonitorMute" language="en_US">
                <synopsis>
                        Mute / unMute a Mixmonitor recording.
                </synopsis>
                <syntax>
                        <xi:include xpointer="xpointer(/docs/manager[@name='Login']/syntax/parameter[@name='ActionID'])" />
                        <parameter name="Channel" required="true">
                                <para>Used to specify the channel to mute.</para>
                        </parameter>
                        <parameter name="Direction">
                                <para>Which part of the recording to mute:  read, write or both (from channel, to channel or both channels).</para>
                        </parameter>
                        <parameter name="State">
                                <para>Turn mute on or off : 1 to turn on, 0 to turn off.</para>
                        </parameter>
                </syntax>
                <description>
                        <para>This action may be used to mute a MixMonitor recording.</para>
                </description>
        </manager>

Which should be pretty easy to parse using php. Is't just a suggestion, possibly saving you a lot of maintenance work

[marcelog]

Currently pami is used to control any asterisk version, without the need of having it installed in the same box as asterisk. So one box can control multiple asterisk installations, with potentially different versions.

How would that work in this case?

[dkgroot]

I do see your point, however there are still a number of ways this could be benifital.

• Include these xml files into your project and use them if there are no local versions available After checkng the version number of the asterisk box you connected to.
• Access an online version if specified server is not "127.0.0.1". It would only have to be parsed once so not that heavy. You can cache a local copy
• Or parse it locally on your system, to generate the Message classes for you (might be helpfull).

There are loads of ways of doing this, just mentioning a few.

Just trying to help you out, focussing your attention on the important stuff :-)

[marcelog]

Generating classes on demand means parsing an xml file of 500k (for asterisk 10, for example), that's a big DOM and will make pami use more memory, more cpu and have a bigger startup time. Accessing it online will only make things worst (latency, network errors, dns poisoning, and so on). And we can't be sure that user will actually generate and install that file. Even more, we can't be sure it will be syntactically correct.

I think that the only viable way of doing this is to have every xml for every asterisk version at the time of the build, and distribute the auto generated classes, without depending on the files that the user provides (and sparing them the need to generate and make them available). It also means that we know for sure what pami will do once it is started, no matter where it's installed.

Also, as you pointed out, we should autodetect the asterisk version and pray for it to be already supported, or choose a compatible version somehow.

What happens with asterisk versions < 1.8? A lot of them are still around and a lot of users still use pami to monitor them.

I'm still not convinced that this would add substantial value (we already have in place a lot of actions and messages written and tested with a lot of different asterisk versions, besides the unit tests), but will probably add a lot of entropy into how pami will work.. and some other things to be concerned about, making debugging more difficult.

Makes sense?

[marcelog]

One more thing: What happens if the xml structure changes? The code will have to support different xml structures depending on the asterisk versions

[dkgroot]

First of: It was only a suggestion :-)

The XML file is generated directly from the source files, so should be as correct as the sources themselves, can't get closer than that. It is delivered with a DTD file, to verify that the XML at least it is syntactically correct. The file structure has not changed since asterisk-1.6.2 as far as i could tell (from a quick snoop).

The size of the file is large: agreed. There is a lot of information that you don't need, so this can be discarded on the first parse, and cache the result locally (possibly in a denser (even binary) format). You could even split by message an load as required to reduce the memory load. There are ways to deal with that.

I do see your point(s) and a lot of work has already been done, kudos to that (This might have made more sense if i had made this comment back in the day when you started). I thought it might be a nice way to provide thirdparty channel driver information in the same format / manner.

Maybe it can be or will be useful in some other way (for example to verify the currently implemented message against).

I will resort to implementing the chan-sccp-b AMI Messages + Tests manually and post a pull request for them when i have some time.

Thanks for a great project by the way.

[marcelog]

Hey I do appreciate the suggestion, and that's why I played a bit with the idea first, and then these questions came to my mind :) Just playing the devil's advocate a bit to see where this leads us.

I think that the more we talk about it, the more details come up and more complexity is added to make it work, and more code is added to support a "simple xml parser" without enough evidence of a clear advantage over a class with a few lines of code (I do agree that we do have a lot of classes lying around, point taken, but nothing more is wrong with that, it just works).

I will close the issue now, but I do look forward to your pull request :) And thanks again for the suggestion, perhaps a working proof of concept might convince me that it's definitely the way to go :)