[
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)
