+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 >
