A7: Backward Compatibility Management Proposal#20
Conversation
muxi
force-pushed
the
backward-compatibility-proposal
branch
from
c852da0 to
9c8ee09
Compare
ctiller
changed the title
|
@a11r ping for review. |
| gRPC server will maintain a list of server workarounds for backward compatibility issues. These workarounds are disabled by default for performance consideration. If a user cares about a backward compatibility issue, they should be able to enable the workaround. In this case gRPC server will identify the version of each client and determine whether the workaround should be applied. | ||
|
|
||
| #### Workaround list | ||
| The workaround list on gRPC server is a map from an integer `workaround id` to a `version comparing function`: |
There was a problem hiding this comment.
Avoid talking implementation details here... we almost certainly won't implement it like this (since this API implies that we'd parse user agent strings N times - and that all workarounds would be triggered by user agent - maybe sometimes we'd want to do something else)
|
|
||
| #### APIs | ||
| ``` | ||
| GRPCAPI void enable_workaround(uint32_t id); |
There was a problem hiding this comment.
Skip discussing the core API's here: instead talk about what abstract API's an implementation must export.
Example:
When building a server, an implementation should support enabling/disabling workarounds by ID. Those ID's should be listed in an enumeration.
| Instead of determining client's compatibility by a minimum version number, we decided to make it more general with `version comparing function`. This allows more flexibility in determining client's compatibility, such as including client's language into consideration. | ||
|
|
||
| ### Performance | ||
| Current API requires a client's `user-agent` string to be checked against the version comparing functions of all items in the workaround list, involving a lot of (likely duplicated) string processing. Depends on how much performance we need, an alternative is to extract key information from `user-agent` (e.g. gRPC version, language, transport, etc.) and use them as parameter of `version comparing functions`. It is a tradeoff of flexibility to performance that we may want to consider. |
There was a problem hiding this comment.
The proposed implementation is an absolute no in terms of performance.
That said, I don't think this RFC needs to consider the actual implementation, and instead concentrate on how this is exposed and how workarounds are to be curated.
muxi
force-pushed
the
backward-compatibility-proposal
branch
from
4db8c30 to
08a4a09
Compare
|
@muxi what's the status of this proposal? Can this be closed? |
5 participants
No description provided.