I would argue that we should not tie any re-writes we want to do if at
all possible.
I think an important part of this conversation should be how we insulate
ourselves and users from API evolution. Waiting until we have a "perfect
API" will result in this never happening. Instead, I would like to come
up with a good way for us to handle a scenario where we have some
current API and want to evolve it (to potentially something incompatible).
For example, I would not want to rewrite SKVI as a part of this
discussion as it would be very impactful on users. However, I would
think we should eventually evolve it to something better. How would we
handle supporting both for some deprecation cycle?
Christopher wrote:
+1 for creating supported interfaces in our public API for these.
Right now, I think all of these areas are suffering from bit rot/technical
debt, and need to be cleaned up before (or in the process of) exposing them
as public API.
On Fri, Aug 26, 2016 at 12:48 PM Josh Elser<[email protected]> wrote:
Hi,
tl;dr Let's brainstorm how we can best provide stability to
user-provided implementations of classes running inside Accumulo
servers, providing client-API guarantees to users and reducing burden on
Accumulo developers to support drift in these APIs.
I had a nice chat with John Vines this morning about a TabletBalancer
compatibility issue that went unnoticed in 1.7.0[1]. This got me
thinking about the number of areas in which we allow for developers to
create their own implementations and plug them into Accumulo servers,
all of which have no API guarantees.
* SortedKeyValueIterator (ugh ugh ugh)
* TabletBalancer
* CompactionStrategy
* VolumeChooser
* Authenticator/Authorizor/PermissionHandler
(There are a few with replication which I'm omitting because I make them
pluggable for internal use -- there is not an expectation that users
would want/need to implement their own variant)
I list these all out to make the argument that we have a repeated issue
across out codebase with providing interfaces/abstract-classes that can
be changed via configuration, informing users of this, but providing no
level of compatibility across releases (not even patch-releases).
In an>=Accumulo-2.0 world, I think it would be prudent to investigate
how we can address this problem to reduce maintenance burden on
ourselves and create supported "public API" interfaces for these. I
imagine that we could come up with a general approach that provides
"guidelines" for how we would handle cases like this in the future.
- Josh
[1] https://issues.apache.org/jira/browse/ACCUMULO-4427
