Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5439E10F27 for ; Sun, 29 Sep 2013 06:12:35 +0000 (UTC) Received: (qmail 90576 invoked by uid 500); 29 Sep 2013 06:12:27 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 90103 invoked by uid 500); 29 Sep 2013 06:12:25 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 90078 invoked by uid 99); 29 Sep 2013 06:12:24 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Sep 2013 06:12:24 +0000 Date: Sun, 29 Sep 2013 06:12:24 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-9681) Basic codec negotiation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Andrew Purtell created HBASE-9681: ------------------------------------- Summary: Basic codec negotiation Key: HBASE-9681 URL: https://issues.apache.org/jira/browse/HBASE-9681 Project: HBase Issue Type: Sub-task Affects Versions: 0.98.0 Reporter: Andrew Purtell Basic codec negotiation: There should be a default codec used for cell encoding over the RPC connection. This should be configurable in the site file. The client can optionally send a message, a manufactured "call" that would otherwise be invalid in some way, to the server asking for a list of supported cell codecs. An older server should simply send back an error because the request is invalid except to servers supporting this feature. A server supporting this feature should send back the requested information or an error indication if something went wrong. The client can optionally send a message, a manufactured "call" that would otherwise be invalid in some way, to the server asking for it to use a given codec for all further communication. Otherwise the server will continue to use the default codec. The server will send back a call response acknowledging the change or an error indication if the request cannot be honored. Server configuration should support mappings from one codec type to another. We need to handle the case where the server has a codec available that extends the requested type but overrides some behavior in the base class, and this is what should be used in lieu of the base type. It must also be possible to choose an alternate default codec which stands in for the default codec, is compatible with client expectations, but changes the server side behavior as needed in the absence of negotiation. -- This message was sent by Atlassian JIRA (v6.1#6144)