Michael's suggestion sounds good to me. Let me try again. I propose we change it to:
gRPC servers should delay the Response-Headers until the first response > message or until the application code chooses to send headers. If the > application code closes the stream with an error before sending headers or > any response messages, gRPC servers should send the error in Trailers-Only. I think these two sentences are now clear. If there is still any ambiguity, suggestions for better phrasing would be appreciated. Thanks, Eric On Thu, Mar 2, 2017 at 6:14 PM, Eric Anderson <ej...@google.com> wrote: > On Thu, Mar 2, 2017 at 4:46 PM, Eric Gribkoff <ericgribk...@google.com> > wrote: > >> Your quote is missing the first part of the sentence. >> >> To avoid unnecessarily committing an RPC on the client, gRPC servers >>> *must* delay sending Response-Headers until the server's first response >>> (a Length-Prefixed-Message) is to be sent on the stream. >> >> >> The intent was "in order to achieve A, you must do B.", not you must >> always do B. If Response-Headers are always immediately sent, retries will >> never be possible. Hence, gRPC servers *"must"* delay the >> Response-Header to avoid unnecessarily committing an RPC. >> > > That is quite ambiguous. To me it reads, "In order for the spec to > maintain property A, you must do B." To be as you say, I would have > expected an "If" or similar conditional at the beginning. Without a > conditional, it always applies (even if only to support a niche use case). > To me there is no ambiguity with *should*, since it is clear it is highly > encouraged but may be optional in some cases, and you know what you would > be losing if you chose not to. > > Using *should* here instead would almost convey the same message, but >> needs further qualification. >> > > Hmm... I guess I just don't see that. > > How about: >> >> If Response-Headers are always immediately sent, retries will never be >>> possible. >> >> > That is not entirely true, due at least to network failures (I'd have to > think about it more to weed out other possibilities). > > Hence, gRPC servers should delay the Response-Header to avoid >> unnecessarily committing an RPC. > > > "delay" is not specific enough. A server should not sleep(1000) before > sending Response-Headers :-). Michael's proposed language seemed fine in > this regard, mostly because it more closely matches the existing language. > > Once Response-Headers are sent, retries will not be possible. > > > Also not entirely true. It matters when they are received, not sent. Sort > of nit, but our specs are so complex, being precise reduces confusion and > effort during reading. > -- 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/CALUXJ7g30XE3GyknazHcVXQs-JGpjLbDTceznLXa_bbkxWum8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
