Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
asfimport opened this issue Feb 21, 2019 · 9 comments
Closed

Comments

@asfimport
Copy link

asfimport commented Feb 21, 2019

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:

PRs and other links:

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

@asfimport
Copy link
Author

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

@asfimport
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@asfimport
Copy link
Author

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants