accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wsla...@gmail.com>
Subject Re: Pros and Cons of moving SKVI to public API
Date Thu, 24 Mar 2016 19:27:37 GMT
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 <ctubbsii@apache.org> 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:
>
> http://mail-archives.apache.org/mod_mbox/accumulo-user/201603.mbox/%3C066a01d17658%24bc9dc1b0%2435d94510%24%40bbn.com%3E
> )
>
> 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?
>

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