[GSoC] RFC: Thrift project proposal (draft)

[Don]

David Nadlinger wrote:
> Hello Robert,
> 
> thank you for taking the time to read my proposal.
> 
> On 3/25/11 5:48 AM, Robert Jacques wrote:
>> First and foremost, I would strongly recommend against looking at
>> Thrifts internals; if you do, the project _should not_ be submitted to
>> Phobos. (Thrift is Apache License 2.0 which isn't compatible with the
>> Boost License). Alternatively, you could aim to get the library into
>> etc.*, or simply make it a D source project. I do feel that aiming for
>> Phobos would strengthen your application though.
> 
> This can certainly be discussed, but I don't think including this 
> project into Phobos would be the best choice – at least as long as an 
> external »interface compiler«, i.e. generator would be used –, but 
> rather trying to make it a part of the official Thrift project. This is 
> how Thrift support was done for other languages, and having the code 
> generator implementation in another project than the library it targets 
> seems not like a wise thing to do.
> 
> Although I'm not a lawyer, I have been involved with D long enough to be 
> aware of a large part of the issues which can originate from Phobos 
> being Boost-licensed. If we decide that we want to have Thrift support 
> in Phobos itself, it would, strictly speaking, become hairy with regards 
> to IP anyway, because at least as far as I can see, some protocol 
> details are in fact implementation-defined.
> 
> Figuring these protocol details out from the code is just what I meant 
> to do anyway, I'll clarify the draft with regard to this.
> 
> 
>> […] But one of the major advantages of CTFE is that there is no 
>> difference between regular D functions and CTFE D, so you can develop 
>> a full Thrift IDL parser/code generator in D and then use it as part 
>> of a build to today and an input to a string mixin tomorrow.I think 
>> playing up D's strengths, and that you are coding with an eye to 
> the future, would strengthen your application.
> 
> To be honest, I don't think this will be possible with D CTFE in thee 
> near future until somebody steps forward and radically improves the 
> current CTFE implementation (thinking of it, this might be a nice 
> project for GSoC as well).

I'm giving CTFE a *major* overhaul right now. I don't know if I'll be 
finished in time for the next compiler release, but definitely by the 
release after that. Most importantly, bug 1330, which is the root cause 
of almost all of the problems, will be fixed. I hope to move CTFE out 
the "experimental feature" category.