I've been holding off making progress on that ticket, because it would
result in too many "svn mv" commands to preserve history. I was
waiting until we switched to git to make progress. Now that we have, I
plan on picking up where I left off, and working that, in conjunction
with ACCUMULO-210. I think some coordination would be helpful, but I
don't want to inhibit your progress.
Essentially, what I was going to do for ACCUMULO-756 was to create an
RPC maven module, with child modules for rpc-api, and rpc-thrift (a
concrete implementation), and was going to push all the thrift code
down to the rpc-thrift module. I was then hoping to specify the rpc
implementation either in configuration (accumulo-site.xml, for now) or
through auto-discovery of concrete implementations on the classpath,
so one could simply swap out implementation jars.
The way this might affect ACCUMULO-1009, depends on how you'd want to
do the implementation. You could simply add configuration to control
the provided thrift implementation to use SSL, or you could create a
separate pluggable implementation that extends the provided one, and
includes the necessary configuration. Another option is to make SSL a
more generic feature for all implementations, and move the
configuration switch up to the rpc-api module, so all other
implementations would have both an SSL and a non-SSL option. I haven't
played with SSL, or touched the RPC stuff in awhile, so I'm not sure
which option is best.
Christopher L Tubbs II
On Wed, Jul 17, 2013 at 12:36 PM, Michael Berman <[EMAIL PROTECTED]> wrote:
> Hi Devs,
> I'm starting work on enabling SSL encryption over the wire (ACCUMULO-1009).
> I noticed ACCUMULO-756 ("abstracting API communication mechanisms") is
> marked as in progress by Christopher. Should I proceed with the SSL changes
> given today's thrift API code, or should I be trying to coordinate with the
> grander abstraction plan? The entrypoint to my changes should be pretty
> focused...just a few lines of code around where we currently create thrift
> servers and clients.
> I'm also open to any other advice about how SSL should be integrated if
> others have particular requirements or solutions in mind.