Hi Woonsan, I've applied the patch as is and all it well. Thank you!
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 in a different package as the API is different), that would give us the most flexibility perhaps. At some point in the future we can decide which provide would be mapped to "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 toggle and test it. Thoughts? Gary On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <woon...@apache.org> 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 <woon...@apache.org> wrote: > > > > Hi Bernd / Experts, > > > > I've submitted a PR for VFS-360. Find my summary in the comment as well. > > - 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 <woon...@apache.org> wrote: > > > Hi Bernd, > > > > > > Thanks for your remarks. Please see my comments inline below. > > > > > > On Wed, Aug 8, 2018 at 3:34 PM, Bernd Eckenfels < > e...@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… 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 solution > > > with HttpComponents HttpClient v4 first. ;-) Also, it's very matured > > > 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 and > > >> http4 component with v4. [1] > > >> A difference is we need one more equivalent to the old 'https', like > > >> 'http4s'. It sounds a bit weird though. > > >> > > >> Any insights? > > >> > > >> Woonsan > > >> > > >> [1] http://camel.apache.org/components.html > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
