Support tcp protocol in R2DBC connection URLs

[odrotbohm]

Currently, only the file and mem protocols are supported and one cannot connect to a locally running H2 instance. Would be cool if that worked.

[katzyn]

I don't think that this issue is fully resolved. Only unencrypted connections are supported. The support for the ssl: protocol is still missing. Also I don't understand why a TCP port is passed as a string. It should be an integer number.

[mp911de]

Integrating remote I/O somewhat defeats the purpose of R2DBC as the general idea is to be non-blocking. We also need to consider URL-based configuration which would be something like:

r2dbc:h2:tcp://<host>:<port>/<database> or r2dbc:h2://<host>:<port>/<database>. For SSL, we should leverage r2dbcs:h2://<host>:<port>/<database>.

We also should put a warning into the readme that in-memory usage is kind-of non-blocking and TCP/SSL transport rely on blocking I/O.

[gregturn]

Good point on port number @katzyn. I’ll fix that immediately.

Regarding ssl, I embarked upon writing the H2 driver based on my own limited understanding of H2. I intended to target the in-memory and file-based aspects to support using it as a test database.

I never thought of doing network I/O. To properly handle network reactively, as @mp911de suggests, would require another level of effort that I don’t (yet) feel is warranted.

Would we all be comfortable with blocking network I/O and no SSL support, or is it better to remove TCP support and clearly denote that H2 support is confined to memory and file based tactics?

[mp911de]

TBCH, File I/O is also blocking. I think, seeing H2 as driver already lets one's eyebrows raise as H2 is JDBC. With clearly stating that it is just a bridge and that folks should not expect non-blocking behavior but rather a tool that allows jumpstarting we should be able to properly manage expectations.

I think if we go for TCP transport, then enabling also SSL transport seems fine.

[gregturn]

Thanks everyone.

See #88 and #89.