Any proposal that adds a dependency to a regex library is an absolute non-starter in my mind.
I'd really encourage solutions that can take the proto data at face value: if client side demuxing needs a more precise view of some data, then perhaps a better solution is to change the proto. On Thu, Feb 2, 2017 at 1:55 PM Alfred Fuller <arful...@google.com> wrote: > To support client-side demultiplexing needed by much of the upcoming > routing technologies, the client needs to be able to extract the exact > piece of information that is relevant. > > The current proposal is the minimal amount of extraction support needed > for the the use cases we are targeting. Any future expansion should be > relegated to standard extraction/transform methods, for example RE2 or CEL. > (I personally would be fine with using RE2 now, though that adds a > dependency on the RE2 lib, where this simple form likely doesn't add any > deps). > > Note that the interpretation of the extracted contents are still opaque to > GRPC. GRPC just needs to be able to test for equality. > > > On Thu, Feb 2, 2017 at 1:43 PM Louis Ryan <lr...@google.com> wrote: > > On Thu, Feb 2, 2017 at 1:19 PM, Alfred Fuller <arful...@google.com> wrote: > > I think this type of config is very service centric, not interface > centric. For example, look at the LRO API. Different services use the same > protobuf, but have different resource name formats. If the requirement was > copy a field verbatim it 'might' work to define the same extraction for all > services that implement LRO, but the requirement here is that the client is > able to uniquely identify an 'affinity key', so the protocol must be able > to extract the exact substring needed. > > > I'm not necessarily saying it has to be codegen though that might be a > reasonable option for a wide variety of folks where interface and service > are not decoupled. > > My primary concern is how much GRPC has to know about whats happening. > GRPC shouldn't have to know anything more than > > 'higher layer please provide me a header value for this opaque rule that I > don't understand' > > perhaps with an indication of whether the provided value is binary or not. > > > > I can also see some services implementing a routing layer that is happy to > inspect everything, and in those cases, no extraction is needed even though > the same interface is exposed. > > Also, this eliminates the problems of clients using old configuration with > new infrastructure. > > So I would say this is not interface configuration, so it should not be in > the interface definition (i.e. the proto files). > > On Thu, Feb 2, 2017 at 1:00 PM Louis Ryan <lr...@google.com> wrote: > > I'm a little confused by this spec. Given that protobuf is backed by a > significant amount of code-generation and expression handling machinery why > is the spec putting responsibility for the extraction and formatting of > these headers on the GRPC runtime? > > Is there some requirement to be able to configure the field extraction > behavior dynamically for APIs that did not anticipate the need for it when > they were launched? If so it seems like that responsibility should rest > entirely on the protobuf runtime and the spec for GRPC should just talk > about how to talk to it to get something extracted. The same would be true > for other encoding runtimes. > > Given that protobuf has (or will have) a standard expression language it > seems like that is what should be passed up to the protobuf runtime > > On Wed, Feb 1, 2017 at 4:28 PM, Alfred Fuller <arful...@google.com> wrote: > > +Trevor Schroeder <trev...@google.com> what is easiest for the GFE and > friends? Base64 decoding a header, url unescaping a header or something > else? > > (I like the idea of %encoding for strings and base64 encoding bytes, > though if I had to pick only one it would probably be base64, as the blowup > from that is fixed and known) > > On Wed, Feb 1, 2017 at 10:02 AM Mark D. Roth <r...@google.com> wrote: > > On Wed, Feb 1, 2017 at 9:57 AM, Eric Anderson <ej...@google.com> wrote: > > On Wed, Feb 1, 2017 at 9:38 AM, Mark D. Roth <r...@google.com> wrote: > > Right off the cuff, I can think of a few possible options here: > > 1. Always base64-encode the extracted values. > 2. Do base64 encoding only when non-ASCII characters are actually present. > 3. Simply strip out non-ASCII characters. > > > There's also the option of encoding the special characters. Say, with > %-encoding. We're doing this for status messages. I think we are sad each > time we have to do this, but it frequently seems to be the least-bad > solution. > > Note this would get pretty strange (from a parsing perspective) when > values are binary, not text. So we may want a different solution for binary. > > > You're right, that is another viable option. And I do like the fact that > it makes things easier to debug in the common case, where the string is > mostly ASCII but may have a small number of non-ASCII characters. > > The down-side of this approach is that, as you pointed out, we would > probably want a separate solution for binary data. That would mean two > different code-paths and probably some way to indicate which one we want to > use for each header extraction spec. > > Alfred, what are you thoughts on all of this? > > > -- > Mark D. Roth <r...@google.com> > Software Engineer > Google, Inc. > > > -- 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/CAAvp3oMGA5FoBpXMtE_eJ0aAtTnjzZiar9pDHQwhJbdX8YSKnA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
