GSOC 2018 ideas

[Charles Cui]

Hi grpc community,

   This is Charles from Columbia University, I saw gRPC is selected in GSOC 2018, and pretty interested in the idea of implementing early OK semantics for gRPC. So, I want to prepare for a proposal based on this idea. Can I have more detailed information of what documents or code that I need to understand? Also, if this idea is allocated to other student (or in other worlds, you prefer some student to work on it), do let me know, so that I can pick some other project. Any comments or suggestions are welcomed!

Hope for your reply!

Thanks Charles!

[Nathaniel Manista]

On Sat, Feb 24, 2018 at 4:41 PM, Charles Cui <charles...@gmail.com> wrote:

   This is Charles from Columbia University,

Pleased to meet you!

I saw gRPC is selected in GSOC 2018, and pretty interested in the idea of implementing early OK semantics for gRPC. So, I want to prepare for a proposal based on this idea. Can I have more detailed information of what documents

There's not a whole lot of documentation around the proposed feature, because it's not so much a new feature as much as filling in a missing corner. Consider a two-by-two matrix of "have read all requests/have not read all requests" and "respond with not-OK status/respond with OK status". It is currently the case that a service-side application:

1) after having read all requests can respond with not-OK status,

2) after having read all requests can respond with OK status,

3) without having read all requests can respond with not-OK status,

4) without having read all requests cannot respond with OK status.

So there's not a whole lot of documentation needed to say "this fourth case should be made to work like the other three".

or code that I need to understand?

The code to understand is gRPC Core - how are RPCs serviced? How do status codes get handled in the course of RPC service?

Any comments or suggestions are welcomed!

Two suggestions spring to mind for this idea:

1) After building gRPC Core and running its tests yourself, draft additional test coverage for the changed behavior, run it, and observe that it fails. Do any tests in the current test corpus depend upon the current behavior?

2) Is there any history to how this case was missed? Are you able to dig through source control history and find anything interesting? How does it look like the current behavior came to be?

Thanks for getting in touch!

-Nathaniel

[Nathaniel Manista]

On Mon, Mar 12, 2018 at 12:07 PM, Nathaniel Manista <nath...@google.com> wrote:

There's not a whole lot of documentation around the proposed feature, because it's not so much a new feature as much as filling in a missing corner. Consider a two-by-two matrix of "have read all requests/have not read all requests" and "respond with not-OK status/respond with OK status". It is currently the case that a service-side application:

1) after having read all requests can respond with not-OK status,

2) after having read all requests can respond with OK status,

3) without having read all requests can respond with not-OK status,

4) without having read all requests cannot respond with OK status.

So there's not a whole lot of documentation needed to say "this fourth case should be made to work like the other three".

Aww fiddlesticks: I really liked this explanation of the behavior to be changed but it turns out that a gRPC team member implemented Early OK last December and failed to update the bug about it. The idea has been removed from our ideas page. My apologies!

-Nathaniel