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
