13 Dec
2016
13 Dec
'16
3:48 p.m.
Hello,
comparing the list of rpc vs mi commands, also taking in consideration
the interest and expressed feedback from the community, there is no
reason to keep MI code longer. Also, during the last days it was
signaled that mi_xmlrpc code will need an upgrade for next versions of
compilers and xmlrpc-c library, so it's better to get rid of it as soon
as possible to avoid work for something to be removed soon.
It should not be any complex work to add the very few missing rpc
commands from the mi alternative, so whoever is using a mi command that
is not yet available as rpc, should open an issue on bug tracker.
Converting the code from mi to rpc is not complex and everyone is
encourage to try converting what they use from mi and it is not a rpc. I
can help troubleshooting, provide guidelines, but I have no time to
setup test environments for modules that I don use and I don't need
those mi/rpc commands.
There is documentation about the RPC API:
- http://www.kamailio.org/docs/docbooks/5.0.x/rpc_api/rpc_api.html
But looking at other modules that have both mi and rpc commands can be a
way to learn quickly how to do it.
In several days I plan to start removing MI code, first in the modules
that have the rpc commands.
Cheers,
Daniel
On 01/12/2016 15:17, Daniel-Constantin Mierla wrote:
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