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