23 Jun
2009
23 Jun
'09
5:54 a.m.
On Dienstag, 23. Juni 2009, Raúl Alexis Betancor Santana wrote:
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".
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
[1] http://www.kamailio.org/mos/view/Contributions/
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 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.