[
https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790081#comment-13790081
]
ramkrishna.s.vasudevan commented on HBASE-9681:
-----------------------------------------------
When codec is getting used say KeyValueCodec we would be using the codec in in
Puts also. Means the server would use the codec to decode the KVs and add it
to the RS.
The same codec will be used by the server while the client issues a scan or
read operation. This means that the codec is uniform in the client and the
server.
For example, take the case of tags, the client should be able to add the tags
through the codec while doing Puts and the server should decode the tags.
Where as while doing the scan the server should suppress the tags using a
different codec and the client should be able to decode KVs using that codec.
Using one codec would be applicable for pure scan cases but when we have read
and writes then both client and server should be aware of its own local and the
remote codec on the other side.
Either we could have a mapping in the server side for the codec specified on
the client side or we should have specific api in the encoder and decoders like
getEncoderForClient, getEncoderForServer.
Anyway this mapping ( we can say as the intelligence added to server to decide
the codec) is always context specific.
> 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)
