osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vfs] new http4 provider, not replace http?


Thanks Woonsan! I applied the patch.

Gary

On Fri, Nov 2, 2018 at 11:49 PM Woonsan Ko <woonsan@xxxxxxxxxx> wrote:

> On Fri, Nov 2, 2018 at 11:16 AM Gary Gregory <garydgregory@xxxxxxxxx>
> wrote:
> >
> > On Fri, Nov 2, 2018 at 9:02 AM Woonsan Ko <woonsan@xxxxxxxxxx> wrote:
> >
> > > Hi Gary,
> > >
> > > On Thu, Nov 1, 2018 at 9:54 PM Gary Gregory <garydgregory@xxxxxxxxx>
> > > 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 <woonsan@xxxxxxxxxx>
> 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 <woonsan@xxxxxxxxxx>
> 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 <woonsan@xxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
> > > > > > >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > > > > > >>
> > > > > > >>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > > > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>