[
https://issues.apache.org/jira/browse/HBASE-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418052#comment-13418052
]
Gregory Chanan commented on HBASE-5447:
---------------------------------------
Some thoughts on this issue...
First off: I'm not sure if this JIRA is referring to the built-in existing
filters, or filters that end-users would write (or some combination of both).
So, what does "custom" mean here? I'm going to refer to both built-in and new
filters below -- I think we need to make a decision for each.
Today, we are using the Writable methods for each filter type in order to
create the Filter on the other end of the rpc (together with the filter class
name, this is enough to construct the filter). This work but means the filters
are not extensible in a forward-compatible way. Options:
1) Require a protobuf definition for each filter class
This would allow us to make each filter forward-compatible in the manner that
all other rpcs are done. I found 16 built-in filter classes where this would
need to be done, so I don't think it's a huge undertaking. I'm even offering
to do it :). I think this is the best option for the built-in filters: most
users probably don't write their own filters and we might as well make them
extensible.
The downside is that for new filters that end-users would write, we would
require them to install pb, write pb definitions, and write java conversions
(convert pb filter to Filter and visa-versa) which makes writing filters for
users more difficult -- they may not even care about forward compatibility.
2) Keep the existing Writable interface (or use something similar)
This would require no work, but doesn't give us forward compatibility.
We could do also a hybrid scheme, where users have the option to either create
PB-compatible filters or Writable filters (e.g. we could have something like
FilterBaseWritable and FilterBasePB), where all our builit-in filters derive
from FilterBasePB and end-users who don't want to mess with PB can just derive
from FilterBasePB (where they are required to implement the readFields and
write methods, as today). The downside here, of course, is more code to
maintain and test for both of the filter base classes.
So, to recap, the questions I think we need to answer are:
A) What should be done about the built-in filters (I suggest converting fully
to PB)
B) What should be done about new filters that end-users write
> Support for custom filters with PB-based RPC
> --------------------------------------------
>
> Key: HBASE-5447
> URL: https://issues.apache.org/jira/browse/HBASE-5447
> Project: HBase
> Issue Type: Sub-task
> Components: ipc, master, migration, regionserver
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
