accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-756) Thrift API should be removed and abstracted
Date Thu, 06 Sep 2012 01:52:07 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449353#comment-13449353
] 

Christopher Tubbs commented on ACCUMULO-756:
--------------------------------------------

I quickly modified the POM files and moved the generated code around to put the thrift stuff
in a separate module to see how easy this would be. There are some issues:

1. I don't have commit access yet, so I can't "svn mv" to keep svn history during refactoring
(so I'll need to work with a committer to reproduce those in a sequence of commits, or else
we lose that info in the patch I would otherwise provide).

2. I don't have a sense of what the abstraction would look like, except possibly just looking
at the thrift definitions and creating Java interfaces that match. Without that, I can simply
move the thrift stuff aside and update the dependencies in the build (which would still be
useful on its own), so we'll need some work on creating the interfaces for the abstraction.

3. We need a name for the sub-modules. I was originally going to call it "accumulo-api", with
"accumulo-api-thrift" as the artifactId for the abstraction and thrift implementation, respectively.
However, "api" is misleading, because somebody might think this contains the public API, which
is actually in the "accumulo-core" artifact (should probably be in a "accumulo-client" one,
but that's a separate concern). "accumulo-rpc" was suggested (with "accumulo-rpc-thrift" being
an implementation).

4. This is not useful to consider yet, because there is only one implementation, but at some
point, some consideration is going to need to be made to decide how to swap out implementations.
This could be done with an annotation scanning framework with drop-in jars, a configuration
change with classes being available on the classpath, or a build-time configuration. This
is a future consideration, though. Not relevant for this ticket... just documenting to put
it on record.
                
> Thrift API should be removed and abstracted
> -------------------------------------------
>
>                 Key: ACCUMULO-756
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-756
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: dist, thrift
>    Affects Versions: 1.5.0
>            Reporter: Christopher Tubbs
>            Assignee: John Vines
>              Labels: api, module, rpc, thrift
>             Fix For: 1.5.0
>
>
> The thrift API for communication between components should be abstracted out and made
more generic, so we can plug in different communications mechanisms. The thrift code generation
and the generated code should be moved to a specific implementation of this abstraction, and
put in a separate sub-module.
> This can help with:
>  1. Making full mocking support easier (ACCUMULO-14) with an in-process "RPC" implementation.
>  2. Testing alternative protocols, like Avro, Protocol Buffers, SSL, etc.
>  3. Minimizing dependencies and isolating thrift generated code from code that is maintained
(ACCUMULO-493).
>  4. Wire compatibility (ACCUMULO-751).
>  5. More?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message