[Format] Flight Location should be more flexible than a (host, port) pair

[asfimport]

The more future-proof solution is probably to define a URI format. gRPC already has something like that, though we might want to define our own format:
https://grpc.io/grpc/cpp/md_doc_naming.html

Reporter: Antoine Pitrou / @pitrou
Assignee: David Li / @lidavidm

Related issues:

• [C++] Add URI parsing facility (Dependency)

PRs and other links:

• GitHub Pull Request #4047

_{Note: This issue was originally created as ARROW-4651. Please see the migration documentation for further details.}

[asfimport]

Antoine Pitrou / @pitrou:
@wesm [~jacques@dremio.com] Comments?

[asfimport]

Jacques Nadeau / @jacques-n:
Generally, I think it is best to avoid adding stuff that we "might" use. I'd also like us to introduce features with reference implementations. Are there specific features someone is building that are blocked by this?

[asfimport]

Antoine Pitrou / @pitrou:
In this case, I was benchmarking Flight over a Unix connection (it's supported by gRPC).

In any case, (host, port) is inflexible, and it's baked in the protocol, which is more delicate to change than an API.

[asfimport]

Jacques Nadeau / @jacques-n:
Inflexible and opinionated can be good when defining a format. Flexibility means that implementations don't work with each other. (There are several places where we already have that problem across our bindings :(.)

I'm all for adding flexibility for real things we want to support assuming as part of that we're including support for those items in at least the C++ and Java libraries.

• If you're arguing to change the protocol to a string field and define a formal URI scheme that only supports host + port right now, I'd be in support of that.
• If you want to extend that to add support for unix domain sockets and the supporting impls, that sounds good as well.

[asfimport]

Antoine Pitrou / @pitrou:
It seems that for C++, we could use this library for URI parsing, which has no external dependencies: https://github.com/cpp-netlib/uri

In Java I'm assuming there's already some standard APIs for that.

[~davidli] what do you think about this proposal?

[asfimport]

Jacques Nadeau / @jacques-n:
Yes, there are many libraries for parsing a URI. I think we should start by supporting protocols that we have reference implementations for.

[asfimport]

Wes McKinney / @wesm:
Changing the protocol to use a well-defined URI specification for locations seems OK to me.

[asfimport]

David Li / @lidavidm:
Sorry, I totally missed this earlier @pitrou. I'd also be in favor of defining a URI in place of the Location struct. It'd be good to then get TLS and domain socket support on top.

[asfimport]

Wes McKinney / @wesm:
Issue resolved by pull request 4047
#4047