accumulo-dev mailing list archives

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

View raw message