Details
Description
I thought it might be useful to start a list of all Kudu features or additions that we suspect may be breaking (i.e. may break client API/ABI compatibility, wire compatibility, on-disk compatibility, etc.) and should be reserved for a Kudu major release, where we could expect to tolerate such breakages.
Here are a few candidates off the top of my head.
Remove std:: classes from C++ client API
The presence of std:: classes complicates maintenance of ABI compatibility w.r.t. libstdc++. Couple options here:
- Replace std:: classes with simpler primitives (i.e. std::string -> void * + size_t).
- Replace std:: classes with Kudu counterparts (i.e. std::string -> faststring).
- Replace entire C++ API with a C-based API.
- Add a C-based API but retain C++ API as header-only.
I believe all of these break ABI compatibility and likely API compatibility too.
Rework Java client async API
When we first released Kudu 1.0 we thought about stabilizing the async Java API (i.e. all public classes that start with Async), but decided against it because we had no good use cases. If we were to do that now, we'd most certainly be breaking ABI/API compatibility for anyone using it in its current form.
Rework status/error codes
This one also comes up from time to time. It bemoans the coarse grainedness of Status' error codes and, depending on how its done, may break client ABI/API compatibility as well as wire compatibility. In addition, generic RPC and application-level RPC errors are messy, and handling RPC's error paths is a pain in the client code.
Attachments
Issue Links
- relates to
-
KUDU-2099 Drop Java 7 Support
-
- Resolved
-