accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: Pros and Cons of moving SKVI to public API
Date Thu, 24 Mar 2016 23:15:50 GMT
On Thu, Mar 24, 2016 at 5:54 PM, Billie Rinaldi <billie.rinaldi@gmail.com>
wrote:

> On Thu, Mar 24, 2016 at 1:15 PM, Christopher <ctubbsii@apache.org> 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.
>
>
> Agreed.  Even if we do create a new API, we can't change or drop the
> existing API without breaking a lot of people's code.  I feel like SKVI is
> in a category of things that we treat as though they're in the public API,
> so we might as well say it is.
>

+1 to that

Ensuring what exists is stable is a separate issue from creating a new
iterator API.


>
>
> > 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 <wslacum@gmail.com>
> 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 <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