I'll note that we're certainly not against the idea of embedding the C/C++ code into other languages as extensions in theory, so long as it can be done cleanly. But I think in practice this often turns out to be harder than it seems, due to different extension models, I/O systems, etc.
One of the core values of Thrift is to be as lightweight and dependency-free as possible, which means we typically prefer native implementations that use standard language components. This makes adoption and installation easier for clients of Thrift who only care about one or two languages (i.e. if you're just using Thrift w/ scripting languages you probably don't want to deal with building and installing extensions, etc.) Cheers, Mark ----- Original Message ----- From: "Bryan Duxbury" <[email protected]> To: <[email protected]> Sent: Friday, February 13, 2009 12:34 PM Subject: Re: Windows support I think it would be a lot more challenging to write one C/C++ extension to rule them all that worked in every client language. If you want to make a new protocol, yes, you'll have to write the code in every client language that you care to use it from. The new Compact Protocol is an example of this. I created the Java implementation to serve as the reference, and myself and others will provide other language implementations as it's needed. -Bryan On Feb 13, 2009, at 12:27 PM, Zhan Xu wrote: > Mark, > > Thanks for the info. > > Does it mean that if I want to extend the message delivery > implementation (e.g. add a new protocol), I have to do the similar > extension multiple times against each language? That's kinda awful... > > Zhan Xu > > On 2/13/09, Mark Slee <[email protected]> wrote: >> The individual language runtime libraries are currently independent. >> Java/perl/php/etc. do not call into the C++ libraries for message >> delivery. >> Rather, they implement message deliviery using the standard I/O >> packages >> available in each language. >> >> >> ----- Original Message ----- >> From: "Zhan Xu" <[email protected]> >> To: <[email protected]> >> Sent: Friday, February 13, 2009 11:02 AM >> Subject: Re: Windows support >> >> >> All (Hannes, Jérémie, David, Esteve and others) >> >> Thanks a lot for the valuable feedbacks! Sounds like there are >> requests/thoughts for Windows support and the community already had >> some initial tries for it. >> >> While browsing the source, I found there are some C# >> codes($thrift/lib/csharp/src) with real implementation (TSocket, >> TBufferedTransport ...) Does that means the Windows issue is just >> for >> C++ run-time library but C# does not have the problem since it's not >> using C/C++ system calls? >> >> This observation leads me to a further question -- what's the >> relationship between the java/perl/php run-time libraries to the c++ >> run-time library? Are those java/perl/php libraries standalone, or >> they call the c++ run-time libraries to do the real message >> delivery? >> >> Zhan Xu >> >>
