[sr-dev] The CURL module

Olle E. Johansson oej at edvina.net
Mon Jul 6 15:07:30 CEST 2015


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




More information about the sr-dev mailing list