[
https://issues.apache.org/jira/browse/THRIFT-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761240#action_12761240
]
stefan Surzycki commented on THRIFT-518:
----------------------------------------
Forgive me for my ignorance, but how does the server handle the headers from
the URLRequest?
A normal thrift call on the wire would look like:
........time.....
One coming from flash would look like:
POST / HTTP/1.1
Host: 10.99.0.118
User-Agent: Adobe Flash Player 10
X-Flash-Version: 10,0,12,36
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
Connection: close
........time.....
Just curious how it works....
> as3/flash/flex generator
> ------------------------
>
> Key: THRIFT-518
> URL: https://issues.apache.org/jira/browse/THRIFT-518
> Project: Thrift
> Issue Type: New Feature
> Reporter: Dave Lerman
> Attachments: thrift_as3.diff, thrift_as3.diff
>
>
> There's been various mailing list discussions about ActionScript 3 support,
> but I didn't see an associated JIRA so I thought I'd create one.
> The goal would be to allow a Flash or Flex project to call a Thrift service
> as an alternative to Flash's built-in web services and RPC implementations.
> A developer might want to use Thrift instead of SOAP, REST or AMF for it's
> code generation, strong typing, or for interoperability with existing
> Thrift-based services.
> The Flash code would look something like:
> {code}
> public function testFunction() {
> var client:Service = new ServiceImpl(new TBinaryProtocol(
> new THttpClient(new URLRequest("http://service.com")));
> client.ping("hello world", handlePingResponse);
> }
> private function handlePingResponse(response:String):void {
> trace("RESPONSE: " + response);
> }
> {code}
> where Service is the generated Flash interface, ServiceImpl is the generated
> client which implements Service, and THttpClient is an implementation of
> TTransport.
> Note that Flash is a single-threaded environment so the call is necessarily
> asynchronous.
> The attached patch is a first-pass at an implementation. It's basically a
> line-for-line partial port of the java lib and generator. The lib contains a
> single protocol (TBinaryProtocol) and a single transport (THttpClient), along
> with a generator which generates the interface and client implementation
> (server implementation is skipped since this seems unlikely to be useful).
> It still needs some work -- it's untested except for the specific thrift
> services we use internally, and needs documentation and cleanup. I'm happy
> to do this work if there's general interest in adding as3 support - let me
> know.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.