Figure out what names we want for Client Foos vs Server Foos about grpc-java HOT 7 CLOSED

Eric, if we adopted the reactive streams API would some of the differences between client and server at the API-level disappear? I suspect not entirely, but it's probably worth some thought ... it would be great if "Call" (or something else) was used on both ends.

from grpc-java.

Based on your preliminary designs, it seemed that we would have "producer" and "consumer" classes/interfaces that would possibly just be swapped between client and server. So yes, it is possible this just goes away to some extent.

from grpc-java.

That would seem to me to be an advantage of adopting that API ... WDYT?

from grpc-java.

Yes, but I strongly question how much concrete benefit we would get from it. The only thing I can think of that would make use it is tying client and server directly together without Channel/Server during testing.

Earlier in the API design we said we weren't going to limit ourselves to using the same API on both sides because of its limited value and strong restriction. I think that is still true. If we can get away with using the same API, great, but it shouldn't limit the design and there are many other attributes of an API that are more important.

from grpc-java.

Agreed, having the same interfaces on client and server is a non-goal. Just thought I might try to complicate this discussion by shouting "Reactive Streams!" :)

from grpc-java.

@ejona86 should we just close this? If we want to pick this discussion back up we could do it in another issue. WDYT?

from grpc-java.

No, we still need it. We aren't consistent at the moment.

from grpc-java.