+1. That's a very good idea, Enis - for HBase 1.0 if possible.
On Mon, Feb 10, 2014 at 2:28 PM, Enis Söztutar <[email protected]> wrote: > Forgot to mention, there was some discussion about filter / coprocessors > versus plugins. It seems that coprocessors are doing both more user-facing > database trigger kind of functionality + some plugging into Hbase internals > functionality. I think longer term, we should define different interfaces > for some pluggable functionality (see recent StorageEngine, Compaction, > Flush, HLog, etc) and keep coprocessors more simple. This was plugins would > be the supported way to extend HBase, and the interfaces would be more > stable. > > > On Mon, Feb 10, 2014 at 2:23 PM, Enis Söztutar <[email protected]> wrote: > > > Awesome work Jeffrey. > > > > Should we name the branch 4.0, instead of 4.0.0? > > > > It would be good to have a list of methods used by Phoenix to be > > identified and tagged in HBase so that at least future changes are not > > completely random. We might start with annotation > > InterfaceAudience.LimitedPrivate, so that HBase devs will be more > careful. > > However, we should also try to make Phoenix not so far-reaching into > HBase > > internals as well. > > > > Enis > > > > > > On Mon, Feb 10, 2014 at 2:16 PM, Andrew Purtell <[email protected] > >wrote: > > > >> On Mon, Feb 10, 2014 at 2:07 PM, James Taylor <[email protected] > >> >wrote: > >> > >> > Mujtaba - would it be > >> > feasible to setup Jenkins builds for this branch as well? > >> > > >> > >> Or, HBase 0.98 is really close to HBase trunk still. If you set up a job > >> building against HBase trunk snapshots (and HBase remembers to publish > >> those...) then Jenkins can catch any incompatibilities accidentally > >> introduced going forward. > >> > >> -- > >> Best regards, > >> > >> - Andy > >> > >> Problems worthy of attack prove their worth by hitting back. - Piet Hein > >> (via Tom White) > >> > > > > >
