accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Pros and Cons of moving SKVI to public API
Date Fri, 25 Mar 2016 00:27:13 GMT
It seems there's a general agreement that we treat it like public API and
we should just call it public API.

I just don't know how we're going to actually say this is public API,
without addressing the issue of the other iterators in the same package,
unless we're okay with going back to a more complicated API definition
which calls out specific classes instead of whole packages.

Keith, you spent the most time thinking about how to convey the public API
in the README. What do you think about how to actually make this happen?

Also, what would we want to say about the 1.6 and 1.7 branches API? Maybe
if we can guarantee that there aren't any changes in those
classes/packages, we can just add them to the README as a new declaration
of API (but not actually an addition in the semver sense), but if there are
any changes, that's going to complicate things, because semver guarantees
should mean no public API changes between bugfix releases. I guess I should
actually check to see if there have been any changes...

On Thu, Mar 24, 2016 at 7:15 PM Keith Turner <keith@deenlo.com> wrote:

> 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