On Dienstag, 23. Juni 2009, Raúl Alexis Betancor Santana wrote:
It would provide access to database (internal database API) not management API. I want alias_db, auth_db, domain, group, usrloc etc. to work directly with HTTP/REST layer.
Why not just provide an HTTP/REST interface to the database, then?
What if I have database, but it is not Mysql/Postgres/Oracle ?
Well, an ODBC connector could be created insted of HTTP/REST one, that will have a very high performance penalty.
Hi Raúl,
there is already a module that connects to ODBC drivers, "db_unixodbc".
What if one have more complex setup than plain tables (subscriber/aliases and so on)? What if one have some CRM or ERP system without direct data access but with some API instead?
If you have such "complex" scenario, you should develop a way to dump your CRM/ERP data into Kamailio structures and not viceversa.
With REST/HTTP layer we can adapt any complex API to SER database API.
NO, what you do is to add another layer, with a very high performance penalty and also with it owns weakness.
In our project we use distributed database without plain tables and plain select/update access.
Think about what Kamailio/Sip-Router needs and if it's better to develop an interface between Kamailio -> YourSystem or it's better to develop an interface between YourSystem -> Kamailio. I think that the second approach would be better.
I can't really comment if its make sense to use such a translation layer as i don't know the system and the exact requirements of the original poster, even if i also like to keep it simple. But if such a translation module is useful to some group, the created code is understandable, documented and maintainable then i don't see a real reason that we this should not be accepted in our repository [1]. Of course it should be implemented in a general way, that it can be changed with some configuration to adapt to different URL schemes, for example, like the SER ldap module.
Henning