23 Jun
2009
23 Jun
'09
9:48 a.m.
Hello!
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other
modules like db_auth.
For access to external data it must use HTTPS-server and use REST-style data access
(http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 =
'somevalue'" it must call
HTTPS-server like this:
GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=som…
Server must return delimiter-separated data.
Similarly (using POST) it must implement support for insert, update and so on.
Of course we would like to see this module inside the main project repository.
If you are interested please contact me for details (requirements, $$).
--
Konstantin
23 Jun
23 Jun
10:02 a.m.
New subject: [Kamailio-Users] [REQ, $] db_rest (or db_http) module for database access
Wouldn't it be simpler to write your own middleware daemon / service
that plumbs the manager interface (FIFO or UDP datagram) to a REST
service exposure in an embedded or peripheral HTTP server, instead of
hooking this straight into the Kamailio core?
Konstantin Cherkasov wrote:
Hello!
Our company seeking for programmer who can create module for flexible database access.
I call it db_rest (or db_http). This module must provide internal database API for other
modules like db_auth.
For access to external data it must use HTTPS-server and use REST-style data access
(http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 =
'somevalue'" it must call
HTTPS-server like this:
GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=som…
Server must return delimiter-separated data.
Similarly (using POST) it must implement support for insert, update and so on.
Of course we would like to see this module inside the main project repository.
If you are interested please contact me for details (requirements, $$).
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
10:04 a.m.
New subject: [Kamailio-Users] [REQ, $] db_rest (or db_http) module for database access
Or MI_XMLRPC, if you can make it compile with that damn old library
version it needs.
Alex Balashov wrote:
Wouldn't it be simpler to write your own
middleware daemon / service
that plumbs the manager interface (FIFO or UDP datagram) to a REST
service exposure in an embedded or peripheral HTTP server, instead of
hooking this straight into the Kamailio core?
Konstantin Cherkasov wrote:
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Hello!
Our company seeking for programmer who can create module for flexible
database access.
I call it db_rest (or db_http). This module must provide internal
database API for other modules like db_auth.
For access to external data it must use HTTPS-server and use
REST-style data access
(http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 =
'somevalue'" it must call
HTTPS-server like this:
GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=som…
Server must return delimiter-separated data.
Similarly (using POST) it must implement support for insert, update
and so on.
Of course we would like to see this module inside the main project
repository.
If you are interested please contact me for details (requirements, $$).
10:45 a.m.
Hello, Alex!
Wouldn't it be simpler to write your own
middleware daemon / service
that plumbs the manager interface (FIFO or UDP datagram) to a REST
service exposure in an embedded or peripheral HTTP server, instead of
hooking this straight into the Kamailio core?
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.
--
Konstantin Cherkasov
10:52 a.m.
New subject: [Kamailio-Users] [REQ, $] db_rest (or db_http) module for database access
Konstantin Cherkasov wrote:
Hello, Alex!
Why not just provide an HTTP/REST interface to the database, then?
Perhaps I am missing something about what you are trying to accomplish,
but it is not entirely clear to me why it is necessary to have an
HTTP/REST layer that specifically utilises the database API in the exact
manner it itself is in turn utilised by those modules, as opposed to
some other manner.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Wouldn't it be simpler to write your own
middleware daemon / service
that plumbs the manager interface (FIFO or UDP datagram) to a REST
service exposure in an embedded or peripheral HTTP server, instead of
hooking this straight into the Kamailio core?
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.
11:06 a.m.
Hello, Alex!
> 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 ?
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?
With REST/HTTP layer we can adapt any complex API to SER database API.
In our project we use distributed database without plain tables and plain select/update
access.
--
Konstantin Cherkasov
11:37 a.m.
On Tuesday 23 June 2009 10:06:25 Konstantin Cherkasov wrote:
Hello, Alex!
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.
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.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
11: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.
11:32 a.m.
On Tuesday 23 June 2009 09:45:03 Konstantin Cherkasov wrote:
Hello, Alex!
This is a very, very, very, very, very bad idea from performance point of view
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Wouldn't it be simpler to write your own
middleware daemon / service
that plumbs the manager interface (FIFO or UDP datagram) to a REST
service exposure in an embedded or peripheral HTTP server, instead of
hooking this straight into the Kamailio core?
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.
11:53 a.m.
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?
--
Konstantin Cherkasov
12:27 p.m.
On Tuesday 23 June 2009 10:53:07 Konstantin Cherkasov wrote:
Hello, Raúl!
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
instead of:
Kamailio <-> LDAP <-> DB
or
Kamailio <-> ODBC <-> DB
You will have a very high performance penalty, moreover on register/location
ops. Think about DB ops that ocurs on timer fires, like location cleaning
ops, nat-pinging ops, etc. buff ...
--
Raúl Alexis Betancor Santana
Dimensión Virtual
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
1:41 p.m.
Добрый день, 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.
--
Konstantin Cherkasov
2:03 p.m.
On Tuesday 23 June 2009 12:41:22 Konstantin Cherkasov wrote:
But it's required for Kamailio to run, you could use whatever you want to
archive this, DB VIEWS, external proc's, etc.
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.
IMHO, you are facing the problem from the wrong side.
What is your final target? a high-end SIP infraestructure or a simple-medium
SIP system liked with a high-end CRM/ERP infraestructure ?
I think the database is the real bottleneck in any
setup.
Yes, that's true, but there are other way of facing that problem.
Can Kamailio connect to several databases? No.
It can, not as you whant .. but it can.
So, we use distributed database cluster (postgres +
pl/proxy) and solve
this bottleneck in our applications.
Similar to that, we use Kamailio+pgpool to archive HA-DB access
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 ? :-)
Yes, we know, at the end it's other DB ;-)
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.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
2:54 p.m.
Hello, Raúl!
> OK, do you ever hear about AUTH_RADIUS ? :-)
Yes, we know, at the end it's other DB ;-)
OK. Can you imagine auth_http in place of auth_radius or auth_diameter ?
I don't think that http with some encapsulated text data is worth then than RADIUS.
But I think auth_http is bad idea. db_rest + auth_db is better.
We can make all db-aware modules work with this "database".
--
Konstantin Cherkasov
3:21 p.m.
On Tuesday 23 June 2009 13:54:01 Konstantin Cherkasov wrote:
Hello, Raúl!
OK. Can you imagine auth_http in place of auth_radius or auth_diameter ?
Yes I can, when I talk about high performance penalty I'm mainly talking about
registrar/location (save() and lookup()) and the related timers fires.
OK, do
you ever hear about AUTH_RADIUS ? :-)
Yes, we know, at the end it's other DB ;-) I don't think that http with some encapsulated
text data is worth then than
RADIUS. But I think auth_http is bad idea. db_rest + auth_db is better.
We can make all db-aware modules work with this "database".
--
Raúl Alexis Betancor Santana
Dimensión Virtual
10:03 a.m.
On Dienstag, 23. Juni 2009, Konstantin Cherkasov wrote:
Our company seeking for programmer who can create
module for flexible
database access.
I call it db_rest (or db_http). This module must provide internal database
API for other modules like db_auth. For access to external data it must use
HTTPS-server and use REST-style data access
(http://en.wikipedia.org/wiki/Representational_State_Transfer).
Instead of making query like "SELECT f1,f2,f3 FROM tableA WHERE f4 =
'somevalue'" it must call HTTPS-server like this:
GET http://hostname/database/tableA&c=f1,f2,f3&k=f4&op=eq&v=som…
Hello Constantin,
you probably already investigated this, but are you aware of the http_query
function in the utils module?
http://www.kamailio.org/docs/modules/1.5.x/utils.html#id2454145
If this don't meet your requirements yet, perhaps it can be extended?
Henning
10:51 a.m.
Hello, Henning!
you probably already investigated this, but are you
aware of the http_query function in the utils module?
If this don't meet your requirements yet, perhaps
it can be extended?
Yes I know about http_query().
But I would like to call save() or locate() or alias_db_lookup() instead of scripting.
--
Konstantin Cherkasov
11:27 a.m.
On Dienstag, 23. Juni 2009, Konstantin Cherkasov wrote:
Hello Konstantin,
understand, you'd like to use the normal DB API to do http queries. There is
the "perlvdb" module in kamailio, and the "ldap" module in ser that
implement
something like a virtual DB interface with interfaces with non-SQL sources.
Perhaps you can take a look to them to get some ideas. It would be also
probably possible to implement this sort of REST-DB translation in perl with
help of the perlvdb module, but don't used this module yet.
Henning
you probably
already investigated this, but are you aware of the
http_query function in the utils module?
http://www.kamailio.org/docs/modules/1.5.x/utils.html#id2454145
If this don't meet your requirements yet, perhaps it can be extended?
Yes I know about http_query().
But I would like to call save() or locate() or alias_db_lookup() instead of
scripting.
5430
days inactive
5430
days old
17 comments
4 participants
participants (4)
-
Alex Balashov -
Henning Westerholt -
Konstantin Cherkasov -
Raúl Alexis Betancor Santana