You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by "Christopher Tubbs (JIRA)" <ji...@apache.org> on 2012/09/06 03:42:07 UTC

[jira] [Created] (ACCUMULO-756) Thrift API should be removed and abstracted

Christopher Tubbs created ACCUMULO-756:
------------------------------------------

             Summary: 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
             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

[jira] [Assigned] (ACCUMULO-756) Thrift API should be removed and abstracted

Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ACCUMULO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Tubbs reassigned ACCUMULO-756:
------------------------------------------

    Assignee: Christopher Tubbs  (was: John Vines)
    
> 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: Christopher Tubbs
>              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

[jira] [Updated] (ACCUMULO-756) Thrift API should be removed and abstracted

Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ACCUMULO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Tubbs updated ACCUMULO-756:
---------------------------------------

    Affects Version/s:     (was: 1.5.0)
    
> 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
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>              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

[jira] [Commented] (ACCUMULO-756) Thrift API should be removed and abstracted

Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
    [ 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

[jira] [Work started] (ACCUMULO-756) Thrift API should be removed and abstracted

Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ACCUMULO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on ACCUMULO-756 started by Christopher Tubbs.

> 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: Christopher Tubbs
>              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