accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject [DISCUSS] How to bring more pluggable interfaces into public API
Date Fri, 26 Aug 2016 16:47:51 GMT
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

Mime
View raw message