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
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
On 01 Jul 2015, at 14:17, Juha Heinanen jh@tutpro.com wrote:
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.
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
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@tutpro.com wrote:
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 06 Jul 2015, at 15:03, Daniel-Constantin Mierla miconda@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@tutpro.com wrote:
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson