Hi Aditya, I think it would be good to have a native client API in 1.0. I can look at the patches when back in the office later this week.
> On Jul 7, 2014, at 9:52 AM, Aditya <adityakish...@gmail.com> wrote: > > Do we want to have the C APIs part of 1.0.0 release. I had posted few > patches and a set of review request sometime last week. > > >> On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis....@gmail.com> wrote: >> >> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <olorinb...@gmail.com> >> wrote: >> >>> Moved ZK watcher & listener subtask out of scope HBASE-10909. Enis - with >>> that, I guess HBASE-10909 can be marked in branch-1? >> >> Sounds good. >> >> >>> >>> HBASE-11464 - this is the jira where I'll capture tasks to abstract hbase >>> client from ZK (mostly it would be post-1.0 work). >> >> Not sure whether we can make it fully backwards compatible with 1.0 >> clients. I guess we will see when the patches are done. >> >> >>> >>> Thanks, >>> Mikhail >>> >>> >>> 2014-07-03 12:52 GMT-07:00 Stack <st...@duboce.net>: >>> >>>> On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <olorinb...@gmail.com >>> >>>> wrote: >>>> >>>>> Guys, >>>>> >>>>> getting back to ZK abstraction work w.r.t. release 1.0 and >> thereafter, >>>> some >>>>> status update. So as we're getting closer to complete HBASE-10909, it >>>> looks >>>>> like the steps may be like this: >>>>> >>>>> - there are 2 subtasks out there not closed yet, one of which is >> about >>>> log >>>>> splitting (and Sergey S has submitted a patch for review), another is >>>>> abstraction of ZK watcher (this is what I've been working on in the >>>>> background; but after sketching the patch it seems like without being >>>> able >>>>> to modify the control flows and some changes in the module structure, >>>> it'd >>>>> be a lot of scaffolding code not really simplifying current code). So >>> I'd >>>>> propose to descope abstraction of ZK watcher jira (HBASE-11073), >>> namely: >>>>> convert it to top-level JIRA and continue to work on it separately; >>>> rename >>>>> HBASE-10909 to "ZK abstraction: phase 1", and mark it as closed as >> soon >>>> as >>>>> log splitting jira is completed. This way HBASE-10909 fits to >> branch-1. >>>> >>>> Sounds good to me. >>>> >>>> >>>>> - secondly, in the discussion to the CatalogTracker patch, we >> started >>>>> talking about modifying client to not know about ZK, but rather keep >>> the >>>>> location of current masters and talk to them using RPC calls. This >> work >>>> can >>>>> not go into branch-1, as it involves invasive changes in client >>> including >>>>> new RPC. As I understand the branching schema now, those changes can >> go >>>> to >>>>> master branch, we just don't merge them to branch-1, and depending on >>>> their >>>>> completeness we can pull them to 1.1 release or so. >>>> >>>> You have it right Mikhail. >>>> >>>> St.Ack >>> >>> >>> >>> -- >>> Thanks, >>> Michael Antonov >>
