1 Jul
2015
1 Jul
'15
2:46 p.m.
Hi!
During July I would like to commit the CURL module to Git - there are developers who wants
to help me to finish it up.
Before doing that, I would like to ask a question (primarily to Juha I think).
I based a lot of this on the existing http_query() function in the "utils"
module. I still have "http_query()" in my module, but
changed it to use my code in the back. It's compatible and a bit enhanced as far as I
see it.
I can either keep it as http_query() with the same name and remove it from utils, or
change the name to something else,
like http_query_plus or http_query_ng, to avoid collissions.
I would prefer removing it from utils and remove the dependency of the curl library from
utils.
What do you think?
/O
1 Jul
1 Jul
3:17 p.m.
Olle E. Johansson writes:
I can either keep it as http_query() with the same
name and remove it
from utils, or change the name to something else,
like http_query_plus or http_query_ng, to avoid collissions.
since http_query would be in another module, i would like to keep the
existing one in order to avoid changes in config files.
why don't you put your curl stuff in existing utils module rather than
introduce a new one? if that is not ok, you could use your curl module
api in utils module to implement your version of http_query.
-- juha
6 Jul
6 Jul
2:29 p.m.
On 01 Jul 2015, at 14:17, Juha Heinanen <jh(a)tutpro.com> wrote:
Olle E. Johansson writes:
Ok, I'll keep it in utils.
I am hoping we can develop an API to make
sure all modules that use CURL use one CURL library binding. When
we have that, we can convert http_query too.
I'll just rename my current version to something else while waiting for the API
to be developed.
Daniel Stenberg points me in that unified APi usage when discussing
binding to CURL from many modules in a multiprocess app. He wasn't
too happy over us linking many modules to the CURL library.
/O
I can either keep it as http_query() with the
same name and remove it
from utils, or change the name to something else,
like http_query_plus or http_query_ng, to avoid collissions.
since http_query would be in another module, i would like to keep the
existing one in order to avoid changes in config files.
why don't you put your curl stuff in existing utils module rather than
introduce a new one? if that is not ok, you could use your curl module
api in utils module to implement your version of http_query.
4:03 p.m.
Hello,
I would suggest to prefix the exported functions with the name of the
module (ie., curl_).
Then try to make the other modules use it -- at least xcap_client could
benefit of it. In long term would be good to have one module depending
on curl library, the other that need libcurt to rely on it (like we do
with mysql or other database modules), so is no need to touch all
modules in case we need to fix something related to curl. I remember
that there were some tricks when initializing the curl lib, specially if
linked with openssl (it has the alternative to use gnutls, though).
Cheers,
Daniel
On 06/07/15 13:29, Olle E. Johansson wrote:
On 01 Jul 2015, at 14:17, Juha Heinanen
<jh(a)tutpro.com> wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Olle E. Johansson writes:
Ok, I'll keep it in utils.
I am hoping we can develop an API to make
sure all modules that use CURL use one CURL library binding. When
we have that, we can convert http_query too.
I'll just rename my current version to something else while waiting for the API
to be developed.
Daniel Stenberg points me in that unified APi usage when discussing
binding to CURL from many modules in a multiprocess app. He wasn't
too happy over us linking many modules to the CURL library.
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev I can either keep it as http_query() with the
same name and remove it
from utils, or change the name to something else,
like http_query_plus or http_query_ng, to avoid collissions.
since http_query
would be in another module, i would like to keep the
existing one in order to avoid changes in config files.
why don't you put your curl stuff in existing utils module rather than
introduce a new one? if that is not ok, you could use your curl module
api in utils module to implement your version of http_query.
4:07 p.m.
On 06 Jul 2015, at 15:03, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
I would suggest to prefix the exported functions with the name of the
module (ie., curl_).
I was thinking of kamcurl or something that never ever would
collide with
anything in the Curl library.
Then try to make the other modules use it -- at least xcap_client could
benefit of it. In long term would be good to have one module depending
on curl library, the other that need libcurt to rely on it (like we do
with mysql or other database modules), so is no need to touch all
modules in case we need to fix something related to curl. I remember
that there were some tricks when initializing the curl lib, specially if
linked with openssl (it has the alternative to use gnutls, though).
Exactly.
But first get the base module working without API, then add the API.
/O
Cheers,
Daniel
On 06/07/15 13:29, Olle E. Johansson wrote:
On 01 Jul 2015, at 14:17, Juha Heinanen
<jh(a)tutpro.com> wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev Olle E. Johansson writes:
Ok, I'll keep it in utils.
I am hoping we can develop an API to make
sure all modules that use CURL use one CURL library binding. When
we have that, we can convert http_query too.
I'll just rename my current version to something else while waiting for the API
to be developed.
Daniel Stenberg points me in that unified APi usage when discussing
binding to CURL from many modules in a multiprocess app. He wasn't
too happy over us linking many modules to the CURL library.
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev I can either keep it as http_query() with the
same name and remove it
from utils, or change the name to something else,
like http_query_plus or http_query_ng, to avoid collissions.
since http_query
would be in another module, i would like to keep the
existing one in order to avoid changes in config files.
why don't you put your curl stuff in existing utils module rather than
introduce a new one? if that is not ok, you could use your curl module
api in utils module to implement your version of http_query.
3430
days inactive
3435
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson