Hello, we started discussing about removing MI (so called management interface) for very long time, more or less since 2008. The RPC should remain the control interface, given its better structure for commands, parameters, etc ... MI is custom protocol using a line-oriented communication via fifo or socket file with kamailio (e.g., implemented mi_fifo and mi_datagram modules). RPC is the alternative, a more standardized concept, with better structured format. I think it's time to set a clear roadmap for doing the removal. Overall, it will be easier to maintain the code, right now being duplicated code for doing the same operation over MI or RPC, and MI shows its limitations (or complexity to deal with) for advanced needs (see the discussions about how to provide multi-line value parameters over MI). So, I want to know if there are many relying on MI directly and they still want to keep it, what would be the expected duration they need for upgrading their tools to work with RPC interface, other relevant aspects people have in favour of mi vs rpc. I am even willing to do the removal in time befire freezing the 5.0 branch. We will ensure a clean start of 5.x series. The main concern from my point of view is kamctl -- but I think we can preserve the compatibility for kamctl commands and parameters (so command line execution of kamctl will be the same), but the output might be different. That's because it should be easy to updated it to communicate with jsonrpc-s module, but then it will get json-formatted results. To summarize, two big questions to answer: a) Are you ok to remove the MI code/commands? b) If yes to a), are you ok to be done for v5.0? Not providing feedback will be considered as 'yes' for both questions, so **speak up if you want MI to be kept or delay it removal**. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

RPC is the alternative, a more standardized concept, with better structured format.

Hello, we started discussing about removing MI (so called management interface) for very long time, more or less since 2008. The RPC should remain the control interface, given its better structure for commands, parameters, etc ... MI is custom protocol using a line-oriented communication via fifo or socket file with kamailio (e.g., implemented mi_fifo and mi_datagram modules). RPC is the alternative, a more standardized concept, with better structured format. I think it's time to set a clear roadmap for doing the removal. Overall, it will be easier to maintain the code, right now being duplicated code for doing the same operation over MI or RPC, and MI shows its limitations (or complexity to deal with) for advanced needs (see the discussions about how to provide multi-line value parameters over MI). So, I want to know if there are many relying on MI directly and they still want to keep it, what would be the expected duration they need for upgrading their tools to work with RPC interface, other relevant aspects people have in favour of mi vs rpc. I am even willing to do the removal in time befire freezing the 5.0 branch. We will ensure a clean start of 5.x series. The main concern from my point of view is kamctl -- but I think we can preserve the compatibility for kamctl commands and parameters (so command line execution of kamctl will be the same), but the output might be different. That's because it should be easy to updated it to communicate with jsonrpc-s module, but then it will get json-formatted results. To summarize, two big questions to answer: a) Are you ok to remove the MI code/commands? b) If yes to a), are you ok to be done for v5.0? Not providing feedback will be considered as 'yes' for both questions, so **speak up if you want MI to be kept or delay it removal**. Cheers, Daniel