thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <ms...@facebook.com>
Subject Re: Windows support
Date Fri, 13 Feb 2009 20:34:49 GMT
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" <bryan@rapleaf.com>
To: <thrift-user@incubator.apache.org>
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 <mslee@facebook.com> 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" <zhan.xu@gmail.com>
>>  To: <thrift-user@incubator.apache.org>
>>  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
>>
>>



Mime
View raw message