Добрый день, Raúl.
On Tuesday 23 June 2009 10:53:07 Konstantin Cherkasov wrote:
Hello, Raúl!
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.
This is a very, very, very, very, very bad idea from performance point of view
Do you realy think that LDAP or ODBC layers is better than HTTP?
Yes, are better, because are protocols with direct access/map to data, HTTP it's a transport protocol, and you are requesting to use REST on top, so ...
Kamailio <-> REST client <-> XML <-> HTTP <-> XML <-> REST server <-> DB
Kamailio is a "REST client" and REST is not requires XML. I think it will be like this: Kamailio <-> (TXT/CSV) <-> HTTP <-> REST server <-> ANY EXTERNAL DB
So, which part is _realy_ slow in this setup? HTTP-server can be very fast. HTTP-server can be load-balanced and distributed. REST layer can be fast and use something like memcached for caching and call distributed database.
I think the database is the real bottleneck in any setup. Can Kamailio connect to several databases? No.
So, we use distributed database cluster (postgres + pl/proxy) and solve this bottleneck in our applications. Now I have headache and have to replicate data from fast distributed cluster to plain tables and FROM(!!!) plain tables to cluster.
instead of: Kamailio <-> LDAP <-> DB or Kamailio <-> ODBC <-> DB
Yes, but what if I don't have plain DB?
OK, do you ever hear about AUTH_RADIUS ? :-)
I just don't want make another stupid auth_SOME, alias_SOME and so on. I think it's better to make db_SOME and use database abstraction layer instead.
Yes, I realize performance challenges. Yes, we must pay for any abstraction.