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
