From dev-return-168810-archive-asf-public=cust-asf.ponee.io@commons.apache.org Fri Nov 2 16:02:40 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6DC1618062B for ; Fri, 2 Nov 2018 16:02:39 +0100 (CET) Received: (qmail 60154 invoked by uid 500); 2 Nov 2018 15:02:38 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 60143 invoked by uid 99); 2 Nov 2018 15:02:38 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2018 15:02:38 +0000 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 53496205 for ; Fri, 2 Nov 2018 15:02:37 +0000 (UTC) Received: by mail-ed1-f49.google.com with SMTP id x2-v6so2097005eds.3 for ; Fri, 02 Nov 2018 08:02:37 -0700 (PDT) X-Gm-Message-State: AGRZ1gJPbeYPa1oMu5OdEL7WryAcIIiQjN6EFKC8a8hBTGGROX0zrSRH 5LwlE9c0M6qcHL8Zp4zdSq+rvtWuzJ43yzdD8BQ= X-Google-Smtp-Source: AJdET5fKjY+m1OD9uWMP/IMAhm9cjdvpIFCDIcb3Ct2I8mQJiZ4nCssuItqnodUGgei77ezmXaoVrZafmxSgqenuVQI= X-Received: by 2002:a17:906:12d3:: with SMTP id l19-v6mr2534851ejb.74.1541170956114; Fri, 02 Nov 2018 08:02:36 -0700 (PDT) MIME-Version: 1.0 References: <5b6b45c0.1c69fb81.51763.7a47@mx.google.com> In-Reply-To: From: Woonsan Ko Date: Fri, 2 Nov 2018 11:02:24 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [vfs] new http4 provider, not replace http? To: Commons Developers List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gary, On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory wrote: > > Hi Woonsan, > > I've applied the patch as is and all it well. Thank you! Thank you very much! > > Food for thought: We should also consider HttpClient *5* which just > released its second beta (I am helping there as well.) > > If you feel like adding another provider for HttpClient 5 Beta 2 (it is i= n > a different package as the API is different), that would give us the most > flexibility perhaps. I do. I'll try it out and hopefully submit a pull request with a new JIRA ticket some day. > > At some point in the future we can decide which provide would be mapped t= o > "http" and "https". > > To that end, I wonder if the current "http" provider based on HttpClient = 3 > should be repackaged as "http3" so that we can create the underlying togg= le > and test it. It seems already possible IIUC: - StandardFileSystemManager's parsing logic on providers.xml allows a provider to register multiple schemes. For example, JarFileProvider has already registered itself with jar, jar, ear, etc. - So, we may set the schemes for the current default HttpFileProvider (HTTPClient3 based) to both "http3" and "http". "http3s" and "https" for the corresponding one accordingly. - At some moment later, when deciding which one to be the default "http" or "https" provider, we can simply change the providers.xml. I will submit another simple PR to set the default ones to [ "http3", "http" ] and [ "http3s", "https" ] soon. Am I in the right track? Woonsan > > Thoughts? > > Gary > > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko wrote: > > > Could someone please review my PR? > > - https://github.com/apache/commons-vfs/pull/38 > > > > Woonsan > > > > > > On Wed, Aug 15, 2018 at 9:11 AM Woonsan Ko wrote: > > > > > > Hi Bernd / Experts, > > > > > > I've submitted a PR for VFS-360. Find my summary in the comment as we= ll. > > > - https://github.com/apache/commons-vfs/pull/38 > > > > > > Could you please review the changes? > > > > > > Thanks in advance, > > > > > > Woonsan > > > > > > > > > On Wed, Aug 8, 2018 at 6:09 PM, Woonsan Ko wrote= : > > > > Hi Bernd, > > > > > > > > Thanks for your remarks. Please see my comments inline below. > > > > > > > > On Wed, Aug 8, 2018 at 3:34 PM, Bernd Eckenfels < > > ecki@zusammenkunft.net> wrote: > > > >> Hello, > > > >> > > > >> I am for http4. In the begining it wont be maped in the > > StandardManager but can be changed later on. > > > > Sounds good to me. > > > > > > > >> > > > >> I do wonder if we can get rid of a Special https Provider and have > > only one (http4) which can handle both Kinds of URLs=E2=80=A6 not quite= sure, what > > do you think? > > > > From user's perspective, it seems better to keep 'https' separately > > > > from 'http'. 'http4s' and 'http4' accordingly. > > > > We can possibly consider nesting or adding somethings in > > > > configuration, for example to allow > > > > 'http4://www.example.com/index.html', > > > > 'http4:http://www.example.com/index.html' (equivalent to the first)= or > > > > 'http4:https://www.example.com/index.html. But that doesn't seem to > > > > make anything more convenient than simply allowing either > > > > 'http4://www.example.com/index.html' or > > > > 'http4s://www.example.com/index.html'. > > > > So, I'm personally inclined to keep the existing pattern to have > > > > separate providers. > > > > > > > >> > > > >> Besides that, I wonder if we also (only?) should consider the new = JDK > > httpclient api? > > > > As I'm trying to scratch my own itch, I'd opt for providing a solut= ion > > > > with HttpComponents HttpClient v4 first. ;-) Also, it's very mature= d > > > > and well-accepted, comparing with the new JDK HttpClient. > > > > I'm open to a possibility in the near future for a new separate > > > > provider, possibly called 'jdkhttp' with JDK HttpClient module. > > > > > > > > Kind regards, > > > > > > > > Woonsan > > > > > > > >> > > > >> Gruss > > > >> Bernd > > > >> > > > >> -- > > > >> http://bernd.eckenfels.net > > > >> > > > >> Von: Woonsan Ko > > > >> Gesendet: Mittwoch, 8. August 2018 18:35 > > > >> An: Commons Developers List > > > >> Betreff: [vfs] new http4 provider, not replace http? > > > >> > > > >> Hi, > > > >> > > > >> I'm trying to contribute for VFS-360. What a nice ticket number! > > > >> After a brief look, I'm considering to add a new provider in a > > > >> separate package, 'http4' (based on HttpComponents HttpClient), > > > >> keeping the old one, 'http' (based on the old Commons HttpClient), > > > >> as-is. The reason is that I don't want to break any public methods= of > > > >> the http provider package in v2.x range. > > > >> > > > >> BTW, Apache Camel has a similar concept: http component with v3 an= d > > > >> http4 component with v4. [1] > > > >> A difference is we need one more equivalent to the old 'https', li= ke > > > >> 'http4s'. It sounds a bit weird though. > > > >> > > > >> Any insights? > > > >> > > > >> Woonsan > > > >> > > > >> [1] http://camel.apache.org/components.html > > > >> > > > >> ------------------------------------------------------------------= --- > > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > > > >> For additional commands, e-mail: dev-help@commons.apache.org > > > >> > > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > > For additional commands, e-mail: dev-help@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org