Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 23 Oct 2014 17:42:35 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12712874.1399478887000.324172.1414086155226@Atlassian.JIRA>
In-Reply-To: <JIRA.12712874.1399478887000@Atlassian.JIRA>
References: <JIRA.12712874.1399478887000@Atlassian.JIRA>
 <JIRA.12712874.1399478887295@arcas>
Subject: [jira] [Commented] (HBASE-11125) Introduce a higher level interface
 for registering interest in coprocessor upcalls
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181625#comment-14181625 ] 

stack commented on HBASE-11125:
-------------------------------

Should we remove this issue from 1.0 since it has no assignee and is seeing no progress?

> Introduce a higher level interface for registering interest in coprocessor upcalls
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-11125
>                 URL: https://issues.apache.org/jira/browse/HBASE-11125
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Andrew Purtell
>            Priority: Critical
>             Fix For: 0.99.2
>
>
> We should introduce a higher level interface for managing the registration of 'user' code for execution from the low level hooks. It should not be necessary for coprocessor implementers to learn the universe of available low level hooks and the subtleties of their placement within HBase core code. Instead the higher level API should allow the implementer to describe their intent and then this API should choose the appropriate low level hook placement.
> A very desirable side effect is a layer of indirection between coprocessor implementers and the actual hooks. This will address the perennial complaint that the low level hooks change too much from release to release, as recently discussed during the RM panel at HBaseCon. If we try to avoid changing the particular placement and arguments of hook functions in response to those complaints, this can be an onerous constraint on necessary internals evolution. Instead we can direct coprocessor implementers to consider the new API and provide the same interface stability guarantees there as we do for client API, 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)