[jira] [Resolved] (THRIFT-1463) Decouple Thrift IDL from generators

["Jake Farrell (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jake Farrell resolved THRIFT-1463.
----------------------------------

       Resolution: Incomplete
    Fix Version/s: 0.9

Bumped to dev mailing list
                
> Decouple Thrift IDL from generators
> -----------------------------------
>
>                 Key: THRIFT-1463
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1463
>             Project: Thrift
>          Issue Type: Wish
>          Components: Compiler (General)
>            Reporter: Diwaker Gupta
>            Assignee: Jake Farrell
>             Fix For: 0.9
>
>
> While Thrift's broad language support is fantastic, it does impose many constraints on day to day development.
> * The current design of the compiler make it hard to improve and test the generator/library for a particular language. The codebase is monolithic and hard to navigate.
> * Each language has it's own idiosyncrasies. For instance, the Java library required ant to build, the Ruby library has other dependencies. Running unit tests is slightly different for each language library. Currently, all of this is duck-taped together (barely) using 'make', which has its own flaws.
> * Adding support for a new language is fairly easy, but rather than making the code more modular, it adds to the current complexity of the codebase. For example, setting up Jenkins jobs to test/verify builds for a new language take a while to come up to parity with other languages.
> I think Google's Protocol Buffer approach is instructive here. They're trying to strip down the core compiler and decouple the IDL from language specific stubs. For a rich environment like Thrift, I think this decoupling is crucial to allow for a more maintainable and testable code base going forward. To refresh:
> * the core compiler takes in a Thrift grammar file and generates an intermediate representation: think of an in-memory AST
> * each supported language will be implemented via plugins, that can be loaded at runtime by the compiler
> * the plugins take this AST and transform it into source code
> * each plugin can be in its own repository (consuming the compiler via a git submodule, for instance). Plugins can freely choose their own build system, unit test frameworks etc
> * a meta repository can contain the compiler, and the 'blessed' (officially supported) languages. This meta repository can include integration tests that will test language interoperability
> I realize, of course, that this will be a big change. But we have to start somewhere.

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