accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Pros and Cons of moving SKVI to public API
Date Thu, 24 Mar 2016 22:09:51 GMT
That was my gut reaction too.

Separating "public API" by artifact would be my preferred way to tackle 
it moving forward. Until then, trying to maintain our current approach 
seems reasonable to me. If there's some reason with how we have things 
structured now which makes this infeasible/difficult, let's by all means 
explore options (I didn't even realize that Yetus had their own audience 

Christopher wrote:
> That's a good idea, at least for now, until we have a proper API jar at
> some hypothetical future point. But, I'd be concerned about adding a
> dependency for users on previous versions (1.6, 1.7) since it has a runtime
> retention.
> We could also make our own annotation, but it'd be nice to take advantage
> of an existing javadoc doclet to do the filtering, like the one Yetus
> provides.
> On Thu, Mar 24, 2016 at 5:49 PM Sean Busbey<>  wrote:
>> We could switch from a list of packages to annotations using the Apache
>> Yetus Audience Annotations.
>> That would allow us to mark specific classes, and even carve out particular
>> methods should we choose.
>> On Thu, Mar 24, 2016 at 3:15 PM, Christopher<>  wrote:
>>> We do have the opportunity to move to a new improved API, if somebody
>> were
>>> to put time into it. I guess that's true whether we put this in the
>> public
>>> API officially or not. I think maybe the hardest part is that we don't
>>> really want to put just the interface in the API... but it exists in a
>>> package with a bunch of other classes which probably shouldn't be public
>>> API. So, some thought needs to be put into *how* we're going to do it,
>> too.
>>> On Thu, Mar 24, 2016 at 3:27 PM William Slacum<>
>> wrote:
>>>> It should be public API. It's one of the core reasons for choosing
>>> Accumulo
>>>> over a similar project like HBase or Cassandra. Allegedly, Jeff "Mean
>>> Gene"
>>>> Dean said we got the concept correct as well :)
>>>> Personally I hate the current API from a usability standpoint (ie, the
>>>> generic types are useless and already encoded in the name, it
>> needlessly
>>>> diverges from the standard java Iterator calling standards), but it's a
>>>> strong, identifying feature we have.
>>>> On Thu, Mar 24, 2016 at 2:50 PM, Christopher<>
>>> wrote:
>>>>> Accumulators,
>>>>> What are the pros and cons that you can see for moving the
>>>>> SortedKeyValueIterator into the public API?
>>>>> Right now, I think there's still some need for improvement in the
>>>> Iterator
>>>>> API, and many of the iterators may not be stable enough to really
>>>> recommend
>>>>> people use without some serious caveats (because we may not be able
>> to
>>>> keep
>>>>> their API stable very easily). So, there's a con.
>>>>> In the pros side, iterators are a core feature of Accumulo, and
>> nearly
>>>> all
>>>>> of Accumulo's distributed processing capabilities are dependent upon
>>>> them.
>>>>> It is reasonable to expect users to take advantage of them, and we've
>>> at
>>>>> least tried to be cautious about changing the iterators in
>> incompatible
>>>>> ways, even if they aren't in the public API.
>>>>> Recently, this came up when we stripped out all the non-public API
>>>> javadocs
>>>>> from the website. (reported by Dan Blum on the user list on March
>> 4th:
>>>>> )
>>>>> What would it take for us to feel comfortable moving them to the
>> public
>>>>> API? Do we need a better interface first, or should we isolate the
>>> other
>>>>> iterators into another package (some of that has already been done),
>> or
>>>>> should we wait for a proper public API package (2.0?) to provide this
>>>>> interface in?
>> --
>> busbey

View raw message