You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Woonsan Ko <wo...@apache.org> on 2018/08/08 16:35:16 UTC
[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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
Hi Gary,
I've just posted a PR for VFS-687 (with HttpClient *5*).
When you have some time, please take a review.
Thanks!
Woonsan
On Wed, Jan 2, 2019 at 12:11 PM Woonsan Ko <wo...@apache.org> wrote:
>
> Thanks again, Gary!
> Just as heads-up, I've created two tickets: VFS-686 and VFS-687. The
> former is about upgrading Jackrabbit dependency on which the webdav FS
> provider depends, and the latter is about adding "http5(s)" FS
> provider as a new http library option.
>
> I will try to submit pull requests for each, one by one--even if it
> takes months on my part time, but please feel free to chime or jump in
> if anyone is interested in.
>
> Kind regards,
>
> Woonsan
>
> On Sat, Nov 3, 2018 at 11:40 PM Gary Gregory <ga...@gmail.com> wrote:
> >
> > Thanks Woonsan! I applied the patch.
> >
> > Gary
> >
> > On Fri, Nov 2, 2018 at 11:49 PM Woonsan Ko <wo...@apache.org> wrote:
> >
> > > On Fri, Nov 2, 2018 at 11:16 AM Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > > On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <wo...@apache.org> wrote:
> > > >
> > > > > Hi Gary,
> > > > >
> > > > > On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com>
> > > > > 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
> > > > > in
> > > > > > 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
> > > > > 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.
> > > > >
> > > > > 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?
> > > > >
> > > >
> > > > I think so :-)
> > >
> > > I thought it could be trivial, but there were somethings more to care.
> > > Now I see... ;-)
> > >
> > > Anyway, I've submitted one more PR for VFS-360:
> > > - https://github.com/apache/commons-vfs/pull/40
> > >
> > > concerning these:
> > >
> > > - Set the old HttpClient v3 provider to both schemes: http3/s, http/s.
> > > So, we can use it through http3/s schemes as well.
> > > - Improved Shell to easily switch providers.xml configuration through
> > > system property. e.g, mvn -Pshell -Dhttp3 -Dhttp4
> > > -Dproviders=providers-http4-default.xml, with an example in
> > > commons-vfs2-examples/ to set http4/s as the default http/s. See the
> > > example test scenarios in commons-vfs2-examples/README.md for detail.
> > > - Added `pwfs` command to print the current working file system, next
> > > to `pwd`, in Shell, which is useful when verifying which file system
> > > is actually used with http/s URLs for example.
> > >
> > > Cheers,
> > >
> > > Woonsan
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > Woonsan
> > > > >
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <wo...@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 <wo...@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 <wo...@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 <
> > > > > > > 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… 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-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
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
Thanks again, Gary!
Just as heads-up, I've created two tickets: VFS-686 and VFS-687. The
former is about upgrading Jackrabbit dependency on which the webdav FS
provider depends, and the latter is about adding "http5(s)" FS
provider as a new http library option.
I will try to submit pull requests for each, one by one--even if it
takes months on my part time, but please feel free to chime or jump in
if anyone is interested in.
Kind regards,
Woonsan
On Sat, Nov 3, 2018 at 11:40 PM Gary Gregory <ga...@gmail.com> wrote:
>
> Thanks Woonsan! I applied the patch.
>
> Gary
>
> On Fri, Nov 2, 2018 at 11:49 PM Woonsan Ko <wo...@apache.org> wrote:
>
> > On Fri, Nov 2, 2018 at 11:16 AM Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <wo...@apache.org> wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com>
> > > > 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
> > > > in
> > > > > 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
> > > > 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.
> > > >
> > > > 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?
> > > >
> > >
> > > I think so :-)
> >
> > I thought it could be trivial, but there were somethings more to care.
> > Now I see... ;-)
> >
> > Anyway, I've submitted one more PR for VFS-360:
> > - https://github.com/apache/commons-vfs/pull/40
> >
> > concerning these:
> >
> > - Set the old HttpClient v3 provider to both schemes: http3/s, http/s.
> > So, we can use it through http3/s schemes as well.
> > - Improved Shell to easily switch providers.xml configuration through
> > system property. e.g, mvn -Pshell -Dhttp3 -Dhttp4
> > -Dproviders=providers-http4-default.xml, with an example in
> > commons-vfs2-examples/ to set http4/s as the default http/s. See the
> > example test scenarios in commons-vfs2-examples/README.md for detail.
> > - Added `pwfs` command to print the current working file system, next
> > to `pwd`, in Shell, which is useful when verifying which file system
> > is actually used with http/s URLs for example.
> >
> > Cheers,
> >
> > Woonsan
> >
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Woonsan
> > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Gary
> > > > >
> > > > > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <wo...@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 <wo...@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 <wo...@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 <
> > > > > > 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… 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-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
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [vfs] new http4 provider, not replace http?
Posted by Gary Gregory <ga...@gmail.com>.
Thanks Woonsan! I applied the patch.
Gary
On Fri, Nov 2, 2018 at 11:49 PM Woonsan Ko <wo...@apache.org> wrote:
> On Fri, Nov 2, 2018 at 11:16 AM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <wo...@apache.org> wrote:
> >
> > > Hi Gary,
> > >
> > > On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com>
> > > 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
> > > in
> > > > 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
> > > 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.
> > >
> > > 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?
> > >
> >
> > I think so :-)
>
> I thought it could be trivial, but there were somethings more to care.
> Now I see... ;-)
>
> Anyway, I've submitted one more PR for VFS-360:
> - https://github.com/apache/commons-vfs/pull/40
>
> concerning these:
>
> - Set the old HttpClient v3 provider to both schemes: http3/s, http/s.
> So, we can use it through http3/s schemes as well.
> - Improved Shell to easily switch providers.xml configuration through
> system property. e.g, mvn -Pshell -Dhttp3 -Dhttp4
> -Dproviders=providers-http4-default.xml, with an example in
> commons-vfs2-examples/ to set http4/s as the default http/s. See the
> example test scenarios in commons-vfs2-examples/README.md for detail.
> - Added `pwfs` command to print the current working file system, next
> to `pwd`, in Shell, which is useful when verifying which file system
> is actually used with http/s URLs for example.
>
> Cheers,
>
> Woonsan
>
> >
> > Gary
> >
> >
> > >
> > > Woonsan
> > >
> > > >
> > > > Thoughts?
> > > >
> > > > Gary
> > > >
> > > > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <wo...@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 <wo...@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 <wo...@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 <
> > > > > 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… 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-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
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
On Fri, Nov 2, 2018 at 11:16 AM Gary Gregory <ga...@gmail.com> wrote:
>
> On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <wo...@apache.org> wrote:
>
> > Hi Gary,
> >
> > On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com>
> > 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
> > in
> > > 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
> > 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.
> >
> > 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?
> >
>
> I think so :-)
I thought it could be trivial, but there were somethings more to care.
Now I see... ;-)
Anyway, I've submitted one more PR for VFS-360:
- https://github.com/apache/commons-vfs/pull/40
concerning these:
- Set the old HttpClient v3 provider to both schemes: http3/s, http/s.
So, we can use it through http3/s schemes as well.
- Improved Shell to easily switch providers.xml configuration through
system property. e.g, mvn -Pshell -Dhttp3 -Dhttp4
-Dproviders=providers-http4-default.xml, with an example in
commons-vfs2-examples/ to set http4/s as the default http/s. See the
example test scenarios in commons-vfs2-examples/README.md for detail.
- Added `pwfs` command to print the current working file system, next
to `pwd`, in Shell, which is useful when verifying which file system
is actually used with http/s URLs for example.
Cheers,
Woonsan
>
> Gary
>
>
> >
> > Woonsan
> >
> > >
> > > Thoughts?
> > >
> > > Gary
> > >
> > > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <wo...@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 <wo...@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 <wo...@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 <
> > > > 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… 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-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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [vfs] new http4 provider, not replace http?
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <wo...@apache.org> wrote:
> Hi Gary,
>
> On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com>
> 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
> in
> > 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
> 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.
>
> 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?
>
I think so :-)
Gary
>
> Woonsan
>
> >
> > Thoughts?
> >
> > Gary
> >
> > On Wed, Oct 31, 2018 at 6:42 PM Woonsan Ko <wo...@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 <wo...@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 <wo...@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 <
> > > 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… 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-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
>
>
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
Hi Gary,
On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <ga...@gmail.com> 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 in
> 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 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.
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 <wo...@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 <wo...@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 <wo...@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 <
> > 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… 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-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
Re: [vfs] new http4 provider, not replace http?
Posted by Gary Gregory <ga...@gmail.com>.
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 <wo...@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 <wo...@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 <wo...@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 <
> 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… 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-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
>
>
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
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 <wo...@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 <wo...@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 <ec...@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-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
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
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 <wo...@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 <ec...@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-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
Re: [vfs] new http4 provider, not replace http?
Posted by Woonsan Ko <wo...@apache.org>.
Hi Bernd,
Thanks for your remarks. Please see my comments inline below.
On Wed, Aug 8, 2018 at 3:34 PM, Bernd Eckenfels <ec...@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-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
Re: [vfs] new http4 provider, not replace http?
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
I am for http4. In the begining it wont be maped in the StandardManager but can be changed later on.
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?
Besides that, I wonder if we also (only?) should consider the new JDK httpclient api?
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org