On 06 Jul 2015, at 15:03, Daniel-Constantin Mierla <[email protected]> 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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
