You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Gulshan Singh <gs...@gmail.com> on 2015/06/01 23:18:52 UTC
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.
Re: HTTP Transport for new language
Posted by Jens Geyer <je...@hotmail.com>.
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: dev@thrift.apache.org
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: dev@thrift.apache.org
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.
Re: HTTP Transport for new language
Posted by Jens Geyer <je...@hotmail.com>.
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: dev@thrift.apache.org
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.
Re: HTTP Transport for new language
Posted by Roger Meier <ro...@bufferoverflow.ch>.
Hi Gulshan
Quoting Gulshan Singh <gs...@gmail.com>:
> I'm helping out with adding support for Rust in Thrift:
> https://github.com/maximg/thrift
cool!
>
> 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.
required things can be added later on, we can also start with basic support
>
> 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.
look at test/cpp/src/TestServer.cpp
you can use make check or CMake to build
>
> 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).
tutorial and integration with the cross test suite (see test/README.md)
of course README.md files or updates to .travis.yml and co are always welcome
>
> 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.
it's just a recommendation,
I think we need to merge https://thrift.apache.org/docs/HowToNewLanguage into
CONTRIBUTING.md ...
all the best!
-roger