Hi Carl, thanks for the quick reply. Let me be more precise. We have a flag --remote_cache= in Bazel that will support a REST based protocol and a gRPC based protocol. So if a user specifies --remote_cache=https://localhost:9988 it means he wants to use the REST protocol and if a user specifies --remote_cache=grpc://localhost:9988 it means he wants to use the gRPC one.
Does that make sense? Best, Jakob Jakob Buchgraber Software Engineer Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. On Thu, Nov 29, 2018 at 8:06 PM 'Carl Mastrangelo' via grpc.io < grpc-io@googlegroups.com> wrote: > Hi Jakob! > > gRPC has it's own name resolution built into it's own URLs, so it may get > confusing. For example, a dns based gRPC service would be > dns:///localhost:9988 . Note the actual address info is in the /path/ of > the URI, rather than the host or authority. For domain socket based > connections, its uds:///tmp/file.sock > > If you plan on supporting the multiple name resolution schemes gRPC has, > you would need to embed the full gRPC URL into the the URL you planned on > using. Like grpc:///dns:///localhost:9988 > > As for the name, I would avoid including the "s" at the end. Several > plaintext protocols are actually secure (such as in memory, UDS, or via a > Secure proxy). If you can limit the scope of supported protocols, you > can probably do something like grpc+plaintext:/// or something along > those lines, as I have seen that elsewhere. > > > HTH, > Carl > > On Thursday, November 29, 2018 at 4:47:08 AM UTC-8, Jakob Buchgraber wrote: >> >> Hi, >> >> in our project we want to allow a user to specify a URI to a service >> endpoint via a flag. We support multiple protocols >> for talking to service endpoints, including gRPC. The current plan is to >> select the protocol to use based on the scheme >> component of the URI. >> >> Do you provide any guidance as to what name to use for the scheme? I was >> thinking "grpc" and "grpcs" to be >> reasonable to choices. >> >> Thanks, >> Jakob >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/grpc-io/dhWHZ3P1ql4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > grpc-io+unsubscr...@googlegroups.com. > To post to this group, send email to grpc-io@googlegroups.com. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/4843f338-47d2-493f-81f6-c28a9f9f4916%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/4843f338-47d2-493f-81f6-c28a9f9f4916%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAGQ4vn31Bvv3_TnyEApFPqdW0%3DHnY-t%3DezW9fVepx7TMbtyxCw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
