accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] How to bring more pluggable interfaces into public API
Date Fri, 26 Aug 2016 16:58:32 GMT
+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 <> 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]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message