+1 (non-binding). I mentioned it in the document but it would be nice to try to maintain standard grpc schemes where applicable.
On Tue, Apr 9, 2019 at 8:26 PM Wes McKinney <wesmck...@gmail.com> wrote: > +1 (binding) > > On Wed, Apr 10, 2019, 2:01 AM Ben Kietzman <ben.kietz...@rstudio.com> > wrote: > > > +1 (non-binding) > > > > On Mon, Apr 8, 2019 at 4:31 PM Bryan Cutler <cutl...@gmail.com> wrote: > > > > > > +1 (non-binding) > > > > > > On Mon, Apr 8, 2019 at 1:07 PM Antoine Pitrou <anto...@python.org> > > wrote: > > > > > > > > > > > +1 (binding). > > > > > > > > Regards > > > > > > > > Antoine. > > > > > > > > > > > > Le 08/04/2019 à 20:36, Antoine Pitrou a écrit : > > > > > > > > > > Hello, > > > > > > > > > > David Li has proposed to make the following change to the Flight > gRPC > > > > > service definition, as explained in this document: > > > > > > > > > > > > https://docs.google.com/document/d/1Eps9eHvBc_qM8nRsTVwVCuWwHoEtQ-a-8Lv5dswuQoM/ > > > > > > > > > > The proposed change is to replace (host, port) pairs to identify > > > > > endpoints with RFC 3986-compliant URIs. This will help describe > with > > > > > much more flexibility how a given Flight stream can be reached, for > > > > > example by allowing different transport protocols (gRPC over TLS or > > Unix > > > > > sockets can be reasonably implemented, but in the future we may > also > > > > > want to implement transport protocols that are not gRPC-based, for > > > > > example a REST protocol directly over HTTP). > > > > > > > > > > An example URI is "grpc+tcp://192.168.0.1:3337". > > > > > > > > > > Please vote whether to accept the changes. The vote will be open > for > > at > > > > > least 72 hours. > > > > > > > > > > [ ] +1 Accept this change to the Flight protocol > > > > > [ ] +0 > > > > > [ ] -1 Do not accept the changes because... > > > > > > > > > > Best regards > > > > > > > > > > Antoine. > > > > > > > > > > > >
