Speaking on behalf of one HBase deployment, we do rely on custom filters, though have so far stayed away from more internal customizations such as co-processors. We've gotten the sense over the years that Filters were fairly stable and seemed more reliable in that sense. I'd be sad if a change like this meant that more caution will need to be used in order to rely on Filters. I understand that some cleanup may need to happen (e.g. HBASE-13346) but hope that we can still be conservative in breaking the Filter apis.
On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <chia7...@apache.org> wrote: > hi stack > I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI. > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote: > > It is an oversight that Filters are not annotated as (limited)private. We > > are unable to guarantee them what public entails given their design is as > > yet imperfect and that they are interpolated at points subject to change. > > > > +1 on taking them limited private in 2.0.0. > > > > Thanks for bringing this up Chia-Ping Tsai. Apt. > > > > St.Ack > > > > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <chia7...@apache.org> > wrote: > > > > > Hi, Folks! > > > > > > We have many powerful callback functions to help user to build amazing > > > application/services. The most of functions are declared as > > > IA.LimitedPrivate excluding the filters. As i see it, the > IA.LimitedPrivate > > > will make the improvement of filter more flexible. Also, we can > introduce > > > more server-side components to filters. > > > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already left the > > > TODO "add filter limited private level" on FilterBase. I feel it is > time to > > > discuss it again. > > > > > > Thanks, > > > Chia-Ping Tsai > > > > > > > > >
