Conversation
srini100
left a comment
srini100
left a comment
There was a problem hiding this comment.
Just a few small nits since we already reviewed this offline.
L50-objc-interceptor.md
Outdated
|
|
||
| gRPC interceptor has been a popular utility for users making HTTP requests. | ||
| gRPC Objective-C library has received a number of requests to add support of | ||
| this feature to gRPC. The old gRPC Objective-C library API was not flexiable enough to support interceptor API. With the [new API](https://github.com/grpc/proposal/blob/master/L38-objc-api-upgrade.md), now it is possible to add in this support. |
| * Collect metrics | ||
| * Obtain/Refresh access tokens | ||
| * Create test stub | ||
| * ... |
There was a problem hiding this comment.
Caching should be a popular one, especially when you already have an example on it.
| * Allows interceptors to specify their own dispatch queue | ||
| * Scope interceptors separately without direct access to each other's states | ||
| * Allows state sharing between interceptors when initiated by the interceptor author | ||
|
|
There was a problem hiding this comment.
In the above lines, clarify if "access" means read or write. If write, you could say something like "Allows modification to...."
|
|
||
| ### Related Proposals: | ||
| The interceptor API is built based on the proposals [L38: Proposal to A New gRPC Objective-C API](https://github.com/grpc/proposal/blob/master/L38-objc-api-upgrade.md) and [L49: gRPC Objective-C Flow Control](https://github.com/grpc/proposal/blob/c28ba74bbacc8c1fb5d269f48d89b06c51d21f44/L49-objc-flow-control.md). | ||
|
|
There was a problem hiding this comment.
The flow control proposal is still marked as in review. It should be changed to approved.
L50-objc-interceptor.md
Outdated
| ### Interceptor Dispatch Queues | ||
| Since each interceptor is stateful, multiple requests or responses issued to an interceptor should be processed in order. That requires the dispatch queues of an interceptor to be serial queue. This requirement currently seems reasonable for us, because multiple calls can each have their own dispatch queue so that the same class of interceptors for different calls can still run concurrently. On the other hand, if serialized process is required across all interceptors of the same class, they will be able to use the same dispatch queue provided by their interceptor factory on initialization. | ||
|
|
||
| In case we have to support concurrent queue in the future, the following alternation may be used to achieve the goal transparently to the users and the interceptor developers: |
There was a problem hiding this comment.
alternation => alternative
There was a problem hiding this comment.
Well I didn't really mean "alternative" too :) But I rephrased it. Thanks Sanjay.
L50-objc-interceptor.md
Outdated
|
|
||
| @end | ||
| ``` | ||
| After all the alternations in the interceptors, GRPCCall2Internal object uses the serializer to transform the data before passing it to core. |
There was a problem hiding this comment.
I thought this was meant to be "alternatives" but probably you meant "alterations" as in updates? In that case "updates" itself might be a better word.
3 participants
Discussion thread: https://groups.google.com/forum/#!topic/grpc-io/7QGmsQW86Ss
Implementation: grpc/grpc#18852