+Abhishek Kumar <abhiku...@google.com> Responding to Abhishek's review comments in the comment thread:
> I am not sure we want all these additional convenience methods. The pro of course is that it these concepts are elevated to the top level in the API. But the con is that the API loses more orthogonality and there are to many ways of accomplishing the same thing. This applies to all the convenience methods in this proposal. For WriteLast at least we also gain the ability to send down a single batch (SEND_MESSAGE + SEND_CLOSE_ON_CLIENT). Without such, implementation options become: - elevate WRITE_BUFFER_HINT to C++ (and lose the ability to write opportunistically if we're writing anyway) - force two round trips through the core stack Both imply some penalty *and* are a harder to discover API. > Per previous discussion, I would recommend adding an option either to the context or the initial metadata send that signals the same buffer-hint that we have in the write options. I've added such overloads to head. On Wed, Jan 18, 2017 at 2:13 PM Craig Tiller <ctil...@google.com> wrote: > Proposal was moved to https://github.com/grpc/proposal/pull/3 (due to > some github forking issues). > > On Sat, Jan 14, 2017 at 11:07 AM Craig Tiller <ctil...@google.com> wrote: > > We don't currently have a cork for initial metadata, but we could get one > by just adding a WriteOptions to the stub stream constructors: that would > be the minimal change. > > Most of the rest of this could be seen as syntactic sugar to help guide > developers into doing the cheaper thing vs the more expensive thing. > > Implementation wise, this also gives us the ability to traverse the core > stack once instead of twice for a corked write. Likely only a win for very > high qps applications (the win is measured in low numbers of microseconds), > but we're starting to see some that would appreciate it. > > On Fri, Jan 13, 2017, 5:29 PM Louis Ryan <lr...@google.com> wrote: > > How is this logically different from per-stream 'corking' ? We want the > ability to coalesce the writes for groups of messages on a stream, not just > the head and tail of a stream, it seems like a generic cork mechanism can > cover headers and trailers too > > On Fri, Jan 13, 2017 at 5:19 PM, 'Craig Tiller' via grpc.io < > grpc-io@googlegroups.com> wrote: > > I've opened a gRFC allowing for coalescing of writes for streaming RPC's > from our C++ API here: https://github.com/grpc/proposal/pull/2 > > Please keep any discussion on this thread. > > -- > 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/CAAvp3oOjheoTeibLGs8GapupvM_gjDJPu9Oq0dTMbzGbJ0mRiw%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAAvp3oOjheoTeibLGs8GapupvM_gjDJPu9Oq0dTMbzGbJ0mRiw%40mail.gmail.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/CAAvp3oPZt6p7fA1%2BoaQLs6NOYAPx3r1DqrLukfRD4tYh%3D156Hw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
