@a11r @tbetbetbe @murgatroid99 @nathanielmanistaatgoogle @jcanizales @jtattermusch

Getting some initial review on API changes in grpc.h (with a demonstration in simple_request.c) would be great at this point, before this work gets too much further.

Also... if anyone wants to start working on this stuff... feel free to branch from this. I'll happily take pull requests on top of it up until it's time to merge it all in (although I hope there's not too much delay on that).

From what I see, grpc.h only has additions, so the change is backward-compatible. Correct?

The plan is to delete anything suffixed with _old at some point in the
not-distant future.

On Tue Feb 03 2015 at 10:00:46 PM Jorge Canizales notifications@github.com
wrote:

From what I see, grpc.h only has additions, so the change is
backward-compatible. Correct?

—
Reply to this email directly or view it on GitHub
#381 (comment).

The meeting yesterday seemed to indicate that there would be a new completion type, which makes sense because grpc_event seems to have a lot of redundancy with grpc_op. What's the deal with that?

So the rough story for grpc_event:

Whilst we need to keep the current core API's alive, we are stuck with a big ugly grpc_event struct.

When we go and delete all _old functions, we can also cleanup grpc_event (and do a minor round of edits to wrappers for compatibility)... I expect that it will end up looking like:

struct grpc_event {
void *tag;
grpc_call *call;
grpc_op_error op_successful;
};

So, when using the new APIs, should I just use those fields? Also, if event will still have a call*, why does grpc_server_request_call need a call**?

You should... for now you'll get a completion of type
GRPC_OP_COMPLETE for any of the new API's... and the accessible fields then
are exactly the ones I described that we'll be moving to.

On Wed Feb 04 2015 at 9:44:25 AM Michael Lumish notifications@github.com
wrote:

So, when using the new APIs, should I just use those fields? Also, if
event will still have a call_, why does grpc_server_request_call need a
call_*?

—
Reply to this email directly or view it on GitHub
#381 (comment).

Tests are still coming... I'll try to get the bulk of them tomorrow. It'd be good to get this in regardless though.

Added more tests and stabilized a bunch

Updated to address comments.