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

["Keith Turner (JIRA)" <ji...@apache.org>]

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

Keith Turner commented on ACCUMULO-756:
---------------------------------------

One problem with this ZooKeeperInstance.getConnector(AuthInfo auth).  This is a public method thats part of the public API, your patch changed the package of AuthInfo so it will break API compat.   I do not know why AuthInfo is in the public API, it should not be, but it is.   The fact that it should not be there is one issue, but it is there and users are probably using it so it should not change.

I create a little script to diff the API.  You can run this, its in test/compat/diffAPI.pl.   It will generate a diff of the public API.  I just ran it to compate 1.4 w/ trunk and saw some issues unrelated to your change.   I did not apply your patch, I just took a glance at it.  I was aware of the issue with AuthInfo being in the public API and caught that.  AuthInfo being in the public API sorta annoys me because its a thrift object, I hope I am not the one who did that :)
                
> 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
>
>         Attachments: ACCUMULO-756.patch
>
>
> 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