[
https://issues.apache.org/jira/browse/HBASE-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790000#comment-13790000
]
ramkrishna.s.vasudevan commented on HBASE-9681:
-----------------------------------------------
Regarding the mapping, how should the server decide on the mapping? Should it
be from a configuration? If it is from a configuration then it is not generic
because this may be context based.
One reason why the mapping is important because in some cases the client may
ask for a codec but it may not be right for the server to send out all the
information say for example some information stored in the tags. So in that
case the server should apply the context based knowledge on what codec it
should use. This is where the mapping comes into picture.
In an internal discussion, there is a chance that for some cases like Export
the server still needs to send out information in tags too. So in that case
the mapping should deal this in a different way.
So overall this mapping and usage of the codecs on the server side is more
context based.
When we have sytem tags in future the above argument applies (generally here it
is better to suppress the tags from the clients).
So the connection negotiation part is a protocol that we can decide but the
mapping is one which is not very generic. Can try to make this mapping a
pluggable one?
> 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)
