From issues-return-81243-archive-asf-public=cust-asf.ponee.io@nifi.apache.org Wed Jul 17 18:22:02 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 05A7B18064E for ; Wed, 17 Jul 2019 20:22:01 +0200 (CEST) Received: (qmail 62129 invoked by uid 500); 17 Jul 2019 18:22:01 -0000 Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list issues@nifi.apache.org Received: (qmail 62113 invoked by uid 99); 17 Jul 2019 18:22:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Jul 2019 18:22:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 51ACEE04AD for ; Wed, 17 Jul 2019 18:22:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 0E14C26587 for ; Wed, 17 Jul 2019 18:22:00 +0000 (UTC) Date: Wed, 17 Jul 2019 18:22:00 +0000 (UTC) From: "Mr TheSegfault (JIRA)" To: issues@nifi.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (MINIFICPP-981) Avoid maintaining our own Curl HTTP Client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MINIFICPP-981?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1= 6887299#comment-16887299 ]=20 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 imp= lementation, primarily because curlpp is dedicated to that task =E2=80=93 s= o they will inherently do it better than all of us. Unless there is a compe= lling reason to not switch to a library like curlpp I think we can implemen= t 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 commun= ity 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.=20 [~aboda] [~mshareef] [~amarmer] and [~bakaid] Thoughts on this? My preferen= ce is to build minifi specific functionality not http client code. What we = have there has known bugs and bugs reported by users =E2=80=93 it's probabl= y 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 imp= lementation, primarily because curlpp is dedicated to that task =E2=80=93 s= o they will inherently do it better than all of us. Unless there is a compe= lling reason to not switch to a library like curlpp I think we can implemen= t this to reduce our overall risk. curlpp's test coverage far exceeds ours. =C2=A0 [~aboda] [~mshareef] [~amarmer] and [~bakaid] Thoughts on this? My preferen= ce is to build minifi specific functionality not http client code. What we = have there has known bugs and bugs reported by users =E2=80=93 it's probabl= y 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 av= oid 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 maintainin= g curl code and use a third party library. -- This message was sent by Atlassian JIRA (v7.6.14#76016)