nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mr TheSegfault (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MINIFICPP-981) Avoid maintaining our own Curl HTTP Client
Date Wed, 17 Jul 2019 18:22:00 GMT

    [ https://issues.apache.org/jira/browse/MINIFICPP-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887299#comment-16887299
] 

Mr TheSegfault edited comment on MINIFICPP-981 at 7/17/19 6:21 PM:
-------------------------------------------------------------------

I would suggest fixing major bugs as we locate them in http client while in tandem wrapping
curlpp. We should discuss what constitutes a major bug for the community. Unfinished functionality
i.e. does not

There is risk in doing so, but let's discuss the risk, while also balancing risk of new dependencies
with the risk of continuing with HttpClient as it is now. I have always been in favor of moving
away from our own custom implementation, primarily because curlpp is dedicated to that task
– so they will inherently do it better than all of us. Unless there is a compelling reason
to not switch to a library like curlpp I think we can implement this to reduce our overall
risk. curlpp's test coverage far exceeds ours ( though it's not superb as I recall ). They
also have a more active community for just a set of http curl related activities


I think this is a good 0.8.0 but I'm willing to move stuff out of 0.7.0 if you all think it
makes sense. 



[~aboda] [~mshareef] [~amarmer] and [~bakaid] Thoughts on this? My preference is to build
minifi specific functionality not http client code. What we have there has known bugs and
bugs reported by users – it's probably time as we build users to move away from a custom
client.


was (Author: phrocker):
I would suggest fixing major bugs as we locate them in http client while in tandem wrapping
curlpp. We should discuss what constitutes a major bug for the community. Unfinished functionality
i.e. does not

There is risk in doing so, but let's discuss the risk, while also balancing risk of new dependencies
with the risk of continuing with HttpClient as it is now. I have always been in favor of moving
away from our own custom implementation, primarily because curlpp is dedicated to that task
– so they will inherently do it better than all of us. Unless there is a compelling reason
to not switch to a library like curlpp I think we can implement this to reduce our overall
risk. curlpp's test coverage far exceeds ours.

 

[~aboda] [~mshareef] [~amarmer] and [~bakaid] Thoughts on this? My preference is to build
minifi specific functionality not http client code. What we have there has known bugs and
bugs reported by users – it's probably time as we build users to move away from a custom
client.

> Avoid maintaining our own Curl HTTP Client
> ------------------------------------------
>
>                 Key: MINIFICPP-981
>                 URL: https://issues.apache.org/jira/browse/MINIFICPP-981
>             Project: Apache NiFi MiNiFi C++
>          Issue Type: Improvement
>            Reporter: Mr TheSegfault
>            Priority: Critical
>             Fix For: 0.8.0
>
>
> [https://github.com/jpbarrette/curlpp] may be a better alternative. I use it on a separate
project and would have preferred starting with that. Some stakeholders did not want us to
use that library, but I think we should avoid maintaining our own client and wasting cycles
to fix bugs. While we can argue that we "know what our bugs are" I don't think that we do
and there are likely many more. Through evolution curlpp has improved and I would not like
to incur that cost on our project. I would prefer to avoid maintaining curl code and use a
third party library.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Mime
View raw message