Hi Rafael
here's my perspective:
1.javascript client in a production environment ?
I like to do so! As soon as I or some of my co-worker have time to fix
at least the map type bug (THRIFT-863) and do additional in deep tests
with the current implementation. That's just one of the reasons why I
provided additional tests for the JavaScript Testsuite within test.html.
Another playground for me is the JavaScript tutorial
https://issues.apache.org/jira/browse/THRIFT-893 that I use to
demonstrate Thrift's simplicity and its usage across Languages... or to
find bugs or neccessary enhancements within the current implementation.
2. configuration on the server side to direct requests to Thrift services?
Apache or Lighttpd proxy module for the Thrift service when using a dedicated
Http server like C++ THttpServer(THRIFT-247) or TServlet running in a Java Web
Container, etc...
My favorit configuration is still a C++ Thrift Server using fastcgi as its
transport connected via web server's fastcgi interface.
From my perspective, Thrift and JavaScript is a real hot combination with a
large potential.
One thing to keep in mind is security!
There is no pluggable security layer available right now, so you need
additional parameters with e.g. a SessionId on each function you define within
your Thridt IDL.
OAuth, SPENGO, pluggable custom auth layer, etc. is future.... but SASL Auth
Layer for JAVA is already here.
Regards
Roger
Am 08.09.2010 19:37, schrieb Rafael Garcia:
The example javascript client in lib/js relies on a barebones http server
(httpd.java) compiled specifically for the ThriftTest service
(ThriftTest.thrift). I have a couple of questions:
1. Are people using the javascript client in a production environment?
2. If so, what's a typical configuration on the server side to direct
requests to Thrift services? The solution provided in httpd.java doesn't
seem very generic, and it's unclear to me how one would accomplish the same
task on a production http server (like apache).
Thanks!
Rafael
