Current Environment
Linux 4.9.0-3-amd64 1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
Asterisk 13.17.0
Pystrix 1.1.2
Summary
Hello, folks! How are you all doing? This is not exactly an error, more like a design question. I noticed that pystrix AMI server does not treats all asterisk's AMI events. I did skim through the code, had both ami server logs and asterisk logs to confirm this. And I know there's a fallback mapping to empty string to catch those events. Was this a design choice? If it was, would you guys spare the knowledge behind it? Also, does the current environment permits creation of this mapping? i.e Create a class that magically maps to a new asterisk event so I can use a callback with it. If so, I might PR this as soon as I grok the code. Might become handy.
Expectations
That each and every single event spitted by asterisk would be correctly mapped to a type. Not everything is candies though. :-)
Workaround
Fallback to empty string mapping and treating by hand. :-(
Cheers!
Current Environment
Linux 4.9.0-3-amd64 1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
Asterisk 13.17.0
Pystrix 1.1.2
Summary
Hello, folks! How are you all doing? This is not exactly an error, more like a design question. I noticed that pystrix AMI server does not treats all asterisk's AMI events. I did skim through the code, had both ami server logs and asterisk logs to confirm this. And I know there's a fallback mapping to empty string to catch those events. Was this a design choice? If it was, would you guys spare the knowledge behind it? Also, does the current environment permits creation of this mapping? i.e Create a class that magically maps to a new asterisk event so I can use a callback with it. If so, I might PR this as soon as I grok the code. Might become handy.
Expectations
That each and every single event spitted by asterisk would be correctly mapped to a type. Not everything is candies though. :-)
Workaround
Fallback to empty string mapping and treating by hand. :-(
Cheers!