Hi Gulshan,
I'm helping out with adding support for Rust in Thrift:
https://github.com/maximg/thrift
Don't know how I managed to not read this. It's late over here, and your
name was totally different, so please just ignore that part in my mail. :-)
And of course, looking forward to Rust as one of the promising newcomers to
become part of the Apache Thrift language family!
Regarding the web site document => done.
@all: As always, if there are any objections/comments/etc. don't hesitate to
comment, or even modify.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Jens Geyer
Sent: Tuesday, June 2, 2015 12:44 AM
To: [email protected]
Subject: Re: HTTP Transport for new language
Hi Gulshan Singh,
that's great. maybe you want to connect with Maxim Golov, who also is
working on Rust bindings for Thrift. It would be awesome if you two guys
could produce something together.
https://github.com/maximg/thrift
I was working on adding an HTTP Transport, as this guide (
https://thrift.apache.org/docs/HowToNewLanguage) says it's one of the
required transports if you want your language merged. After running into
some bugs while implementing it, I took a look at some of the other
implementations.
The information in that document are picked from various sources and things
change over time, but I think you are right and we can make HTTP
"recommended". However, while changing this, I will promote the multiplex
transport to required. It is not hard to implement, highly useful and
emerged into a "must-have" in the last months.
Having HTTP as transport available ist still a good idea - especially for
clients.
I'm wondering now how necessary it is to implement this transport for a
new
language. I don't think I've ever seen it used, as it's slower than
regular
sockets and provides no benefit. I don't see any standard/documentation
for
this transport, so bugs like missing the content-length in the python
implementation have popped up and make it not work with other languages.
I personally had no issues with HTTP clients so far, but maybe it is because
we only use IIS servers here.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Gulshan Singh
Sent: Monday, June 1, 2015 11:18 PM
To: [email protected]
Subject: HTTP Transport for new language
I'm helping out with adding support for Rust in Thrift:
https://github.com/maximg/thrift
I was working on adding an HTTP Transport, as this guide (
https://thrift.apache.org/docs/HowToNewLanguage) says it's one of the
required transports if you want your language merged. After running into
some bugs while implementing it, I took a look at some of the other
implementations.
The Python THttpServer doesn't send back the content-length, so using it
with implementations like C++ break, as they rely on this content-length
(my Rust implementation broke too). I fixed this on my local copy and ran
into some more bugs, so I decided to try running the C++ THttpServer
instead to make sure it wasn't some more weird python implementation bugs.
However, I couldn't figure out how to run it, since it doesn't inherit from
TServerTransport.
I'm wondering now how necessary it is to implement this transport for a new
language. I don't think I've ever seen it used, as it's slower than regular
sockets and provides no benefit. I don't see any standard/documentation for
this transport, so bugs like missing the content-length in the python
implementation have popped up and make it not work with other languages.
And finally I can't even figure out how to run it in C++, which makes it
hard for me to develop my own implementation if I don't have a standard or
a correct reference implementation to look at (although this might be an
oversight on my part, please let me know if there's a way to run this).
So in short, should the requirement to implement the HTTP transport for a
new language be relaxed to just a recommendation (or even removed from the
document altogether)? And if not, some help in getting the C++
implementation up and running would be appreciated.
