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 20:55:59 GMT
I think there's definitely (at least?) two categories of public API's in 
play. What we have now is definitely "end-user" focused. All of the 
things that we expect users to do fall into this.

However, we have this odd "super-user" category too. Iterators, custom 
server-side implementations all require an additional degree of 
understanding to do both safely and correctly.

My motivation is that I believe we should be striving for compatibility 
on both of these categories (for both types of users). I'm sure those 
who write Iterators are smart enough to understand how to update them 
for some interface change; but, can't we do better than that in 
Accumulo? I think this also touches on the recent maintenance tail 
conversations from the JDK8 discussion: breakages here are just another 
reason (excuse?) for people to avoid upgrading.

Perhaps such APIs are held to a lesser standard than our public API? 
Maybe we start with some subset of semver and see how it goes? I think 
these are all great points to consider. Presently, we have nothing; I 
know we can do better than that.

Marc P. wrote:
> I tend to think that what can be configured now is tailored to the
> infrastructure engineers? With the exception of SKVI, is it short sighted
> to suggest that the consumers of said APIs are generally few and far
> between?  Those flexible APIs exist for the John "Ain't no mountain high
> enough" Vines of the world.
> My point is that breaking an API into public and private makes maintenance
> difficult because you have few people that understand certain portions of
> the code. Furthermore, there is frustration in making changes at certain
> levels. Could there be value in defining layers of API responsibility that
> dictate for who or whom these APIs may be useful but also differentiate
> temporal stability? i.e. scanner API is slightly more consumer focused and
> is stabilized much more than tablet balancers, where changes may occur at a
> greater frequency?
> On Fri, Aug 26, 2016 at 1:24 PM, Sean Busbey<>  wrote:
>> On Fri, Aug 26, 2016 at 11:58 AM, 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.
>> Can we make this clean up a goal for a>=Accumulo 3.0 world? Or since
>> we'd be adding to the public API maybe>=Accumulo 2.y for some y>= 1?
>> We're long for a 2.0 release, and the sooner we get it out the door
>> (if only just for the java 8+ only change) the better chances we're
>> giving to downstream folks to move to it in an orderly manner. I'd
>> prefer we not delay that further for API additions. (IIRC, that's why
>> we didn't have a 2.0 release last year?)
>>> On Fri, Aug 26, 2016 at 12:48 PM Josh Elser<>
>> wrote:
>>>> 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.
>> Another option would be that we expressly make these pluggable parts
>> "use at your own risk" internals with a weaker compatibility promise
>> than semver.  We could, for example, label these points as something
>> that we won't break in a double-dot release (e.g. whatever works in
>> 1.7.0 will work in 1.7.z) but still give ourselves the room to change
>> them in minor releases.
>> I primarily mention this because we don't have an established history
>> for maintaining code lines across major version releases, so I'm
>> skeptical of things that will force us to increment the version in the
>> master branch across major #s.
>> --
>> busbey

View raw message