Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9ZXHDk1hqk_Su9beryu-z4bjCS5oJQiGH9e+vNvCnRaDQ@mail.gmail.com>
References: 
 <CAL5zq9ZJdhxK=mGwX3MDVSGb_EmFJC=5cFx77AoL98myLszJHw@mail.gmail.com>
 <CALs3O6jLZZ9UvUfOjJrzrJ3zv24uqMKD9m7DZCtfsUjnWT7YfQ@mail.gmail.com>
 <CAL5zq9ZXHDk1hqk_Su9beryu-z4bjCS5oJQiGH9e+vNvCnRaDQ@mail.gmail.com>
From: Sean Busbey <busbey@cloudera.com>
Date: Thu, 24 Mar 2016 16:48:38 -0500
Message-ID: 
 <CAGHyZ6Lcp1TRs_rasRkJgWHhBmHf3TsMO6sv2kbbgR=WEECr-Q@mail.gmail.com>
Subject: Re: Pros and Cons of moving SKVI to public API
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3409ae8210b052ed26904

--001a11c3409ae8210b052ed26904
Content-Type: text/plain; charset=UTF-8

We could switch from a list of packages to annotations using the Apache
Yetus Audience Annotations.

http://yetus.apache.org/documentation/0.2.0/#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 <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. 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?
> > >
> >
>


-- 
busbey

--001a11c3409ae8210b052ed26904--