Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
Patch Available
Description
As some of you might remember, I started working on D programming language support for Thrift during the 2011 Google Summer of Code. After many unexpected delays, the time has finally come where both the code is stable - that is, ready for upstream merging, I hope - and I can spare enough time to focus any further issues that should pop up.
The library generally tries to follow the precedent set by C++ and Java in design and, in some places, implementation. What is pretty unique, though, is that most of the actual code generation is done at D compile time, the Thrift compiler module for D does little more than providing a direct translation of the IDL file(s) into D code.
What is done:
- Binary/Compact/JSON protocols
- Socket, SSL, HTTP and file transports (plus your familiar helpers, i.e. buffered/framed/memory-buffer/piped/zlib...)
- Several single- and multithreaded server variants (including a libevent-based non-blocking implementation)
- Both synchronous and asynchronous client implementations
- Reasonably good test suite coverage
Wish/Todo list:
- Unix domain sockets - the D standard library will start to properly support them in the next release
- More real-world battle testing (most testing has been done using synthetic test cases similar to the other languages; and while I know of a few people intending to use Thrift/D in the wild, I still need to inquire about the current status of their projects)
I have been developing the project in my own fork over at GitHub, attached is a (large) patch against current trunk. Using a current D compiler, the test suite should pass on Linux x86/x86_64, OS X x86/x86_64 and Windows x86. The necessary dependencies are detected by configure. At the GitHub project wiki, I put together an introduction and build instructions, which could e.g. be moved to the Thrift wiki. A recent build of the API documentation can currently be found at my personal website.
Please let me know about the best way to go forward with this, and feel free to let me know of any issues with the code you might come across (the build system integration could particularly use a look, Autotools isn't exactly my strength). If the code will make its way into trunk, I will also be happy to fill out any necessary legal paperwork, I'm just not quite sure what is required by the ASF in that regard.