User Tools

Site Tools


devel:libcurl_integration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
devel:libcurl_integration [2016/01/28 20:43]
hugh.waite created
devel:libcurl_integration [2016/02/03 11:04] (current)
oej [Discussion]
Line 14: Line 14:
  
 ==== Requirements ==== ==== Requirements ====
-  Synchronous queries +  Synchronous queries 
-  Asynchronous queries that suspend the transaction and resume on completion +  Asynchronous queries that suspend the transaction and resume on completion 
-  Asynchronous queries that call an event_route on completion +  Asynchronous queries that call an event_route on completion 
-  Ability to configure 'named connections' with preset curl options (keys/certs, verify flags etc) +  Ability to configure 'named connections' with preset curl options (keys/certs, verify flags etc) 
-  query functions exported via a C API to other modules+  query functions exported via a C API to other modules
 Any more? Any more?
 See also [[https://github.com/kamailio/kamailio/blob/master/modules/curl/TODO.txt|TODO.txt]] in the curl module See also [[https://github.com/kamailio/kamailio/blob/master/modules/curl/TODO.txt|TODO.txt]] in the curl module
  
 +  * Ability to pass a list of HTTP header to add
 +  * Ability to retrieve response headers (e.g. header callback function) - required for xcap_client module
 +
 +==== Discussion ====
 The curl module currently offers a synchronous query function which can use named connections set up in modparams. Client certificates and parameters can be configured globally or per connection and there is an exported API. This uses the curl 'easy' interface without worker processes. The curl module currently offers a synchronous query function which can use named connections set up in modparams. Client certificates and parameters can be configured globally or per connection and there is an exported API. This uses the curl 'easy' interface without worker processes.
  
Line 28: Line 32:
 The final solution will be a combination of these, however consensus should be reached on the architecture. The final solution will be a combination of these, however consensus should be reached on the architecture.
 Should these be combined into a single module, or should one depend on the other? Should these be combined into a single module, or should one depend on the other?
-It should of course be easy to understand and use.+It should of course be easy to understand by the end user. 
 + 
 +Items to discuss: 
 +  * Name of modules(s) 
 +  * Definition of API functions and parameters 
 +  * Use of worker pools 
 + 
 +Names 
 +  * The curl module has been renamed to "Http_client" 
 +  * Need new name for the new module
  
 Please add your own comments below (hpw) Please add your own comments below (hpw)
 +
 +  * (gv) I think it was mentioned at the meeting in Brussels: it would be nice to have a separate configuration file with the "connections", which can be reloaded at run time (like http://kamailio.org/docs/modules/stable/modules/tls.html#tls.r.tls.reload).
 +  * (oej) The "curl" prefix needs to go away from the functions, parameters and api in the http_client module. New names discussed on sr-dev
devel/libcurl_integration.1454010208.txt.gz · Last modified: 2016/01/28 20:43 by hugh.waite