Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of anoop.hbase@gmail.com
 designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADcMMgHqmNiPRRCgt6nGuBMqLZRp=My5fsQfMTgdvwEW26KngA@mail.gmail.com>
References: 
 <CAAT7MkovsSP0o=hpErm6i9W6kM1q=Pv7jn=oASOKr7rh-mFHyw@mail.gmail.com>
	<CADcMMgHqmNiPRRCgt6nGuBMqLZRp=My5fsQfMTgdvwEW26KngA@mail.gmail.com>
Date: Tue, 6 Aug 2013 09:16:13 +0530
Message-ID: 
 <CAOtJ30r8LH4zaa14iJ=haqCW3X=CXfsYL+70mMBQfjdg8k5oMg@mail.gmail.com>
Subject: Re: Having different codecs between Client and Server
From: Anoop John <anoop.hbase@gmail.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7b672a12305c7504e33f44a8

--047d7b672a12305c7504e33f44a8
Content-Type: text/plain; charset=ISO-8859-1

>Could the codec itself figure its context and act appropriately?

+1 for this.

-Anoop-

On Tue, Aug 6, 2013 at 3:52 AM, Stack <stack@duboce.net> wrote:

>  On Mon, Aug 5, 2013 at 1:04 PM, ramkrishna vasudevan <
> ramkrishna.s.vasudevan@gmail.com> wrote:
>
> > Hi
> >
> > Currently in the RPC client we can configure the codec but the same codec
> > would apply to the client and the server.
> >
> > If we could configure a different codec for the server to client
> > communication it could help us in some cases.
> >
> > For example, if we need to remove the tags from sending it to the client
> > then having a new KV Codec on the server side would help to remove the
> tags
> > before sending it to the client for security usecases.
> >
> > So when we move to Cells later this type of selecting codecs would would
> > really be useful.
> >
> > Am i missing something here? Thoughts on this?
> >
>
> Makes sense.
>
> We don't have vocabulary for doing this currently.
>
> Could the codec itself figure its context and act appropriately?
>
> St.Ack
>

--047d7b672a12305c7504e33f44a8--