[vfs] new http4 provider, not replace http?

Discussion:

Woonsan Ko

2018-08-08 16:35:16 UTC

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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Bernd Eckenfels

2018-08-08 19:34:22 UTC

Permalink

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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Woonsan Ko

2018-08-08 22:09:51 UTC

Permalink

Hi Bernd,

Thanks for your remarks. Please see my comments inline below.

Post by Bernd Eckenfels
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.

Post by Bernd Eckenfels
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.

Post by Bernd Eckenfels
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

Post by Bernd Eckenfels
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-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Woonsan Ko

2018-08-15 13:11:58 UTC

Permalink

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

Post by Woonsan Ko
Hi Bernd,
Thanks for your remarks. Please see my comments inline below.

Post by Bernd Eckenfels
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.

Post by Bernd Eckenfels
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?

Post by Bernd Eckenfels
Besides that, I wonder if we also (only?) should consider the new JDK httpclient api?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Woonsan Ko

2018-11-01 00:42:40 UTC

Permalink

Could someone please review my PR?
- https://github.com/apache/commons-vfs/pull/38

Woonsan

Post by Woonsan Ko
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

Post by Woonsan Ko
Hi Bernd,
Thanks for your remarks. Please see my comments inline below.

Post by Bernd Eckenfels
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.

Post by Bernd Eckenfels
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?

Post by Bernd Eckenfels
Besides that, I wonder if we also (only?) should consider the new JDK httpclient api?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Gary Gregory

2018-11-02 01:53:39 UTC

Permalink

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

Post by Woonsan Ko
Could someone please review my PR?
- https://github.com/apache/commons-vfs/pull/38
Woonsan

Post by Woonsan Ko
Hi Bernd,
Thanks for your remarks. Please see my comments inline below.
On Wed, Aug 8, 2018 at 3:34 PM, Bernd Eckenfels <

Post by Bernd Eckenfels
Hello,
I am for http4. In the begining it wont be maped in the

StandardManager but can be changed later on.

Post by Woonsan Ko

Post by Woonsan Ko
Sounds good to me.

Post by Bernd Eckenfels
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?

Post by Woonsan Ko

Post by Woonsan Ko
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.

Post by Bernd Eckenfels
Besides that, I wonder if we also (only?) should consider the new JDK

httpclient api?

Post by Woonsan Ko

Post by Woonsan Ko
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

---------------------------------------------------------------------

Woonsan Ko

2018-11-02 15:02:24 UTC

Permalink

Hi Gary,

Post by Gary Gregory
Hi Woonsan,
I've applied the patch as is and all it well. Thank you!

Thank you very much!

Post by Gary Gregory
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.

Post by Gary Gregory
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

Post by Gary Gregory
Thoughts?
Gary

Post by Woonsan Ko
Could someone please review my PR?
- https://github.com/apache/commons-vfs/pull/38
Woonsan

Post by Woonsan Ko
Hi Bernd,
Thanks for your remarks. Please see my comments inline below.
On Wed, Aug 8, 2018 at 3:34 PM, Bernd Eckenfels <

Post by Bernd Eckenfels
Hello,
I am for http4. In the begining it wont be maped in the

StandardManager but can be changed later on.

Post by Woonsan Ko

Post by Woonsan Ko
Sounds good to me.

Post by Bernd Eckenfels
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?

Post by Woonsan Ko

Post by Bernd Eckenfels
Besides that, I wonder if we also (only?) should consider the new JDK

httpclient api?

Post by Woonsan Ko

---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@commons.apache.org
For additional commands, e-mail: dev-***@commons.apache.org

Gary Gregory

2018-11-02 15:15:56 UTC

Permalink

Post by Woonsan Ko
Hi Gary,

Post by Gary Gregory
Hi Woonsan,
I've applied the patch as is and all it well. Thank you!

Thank you very much!

Post by Gary Gregory
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.

Post by Gary Gregory
At some point in the future we can decide which provide would be mapped

Post by Gary Gregory
"http" and "https".
To that end, I wonder if the current "http" provider based on HttpClient

Post by Gary Gregory
should be repackaged as "http3" so that we can create the underlying

toggle

Post by Gary Gregory
and test it.

- 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

Post by Woonsan Ko
Woonsan

Post by Gary Gregory
Thoughts?
Gary

Post by Woonsan Ko
Could someone please review my PR?
- https://github.com/apache/commons-vfs/pull/38
Woonsan

Post by Woonsan Ko
Hi Bernd / Experts,
I've submitted a PR for VFS-360. Find my summary in the comment as

well.