How to talk with C++ Thrift part from GWT-RPC-PLUS?

108 views
Skip to first unread message

seas

unread,
Sep 2, 2010, 4:32:20 AM9/2/10
to DotSpots Open Source
Hi,

Probably, I am missing something, but I cannot talk to the code I
generated with Thrift C++ compiler.
GWT-RPC-PLUS and native C++ compiler use the different notation,
Native compiler is more verbose.
So, for the same IDL:
service Service {
i32 xxx(1:string login, 2:string password)
}
GWT-RPC-PLUS generates the following request:
[0,"xxx",null,["adf\","adf\"]]

And C++ Thrift client would give:
[1,"xxx",1,0,{"1":{"str":"abc"},"2":{"str":"bcd"}}]

So, I see they expect a different format.
I it possible to communicate GWT-RPC-PLUS based client and Native C++
Thrift server? (without generating server-side with GWT-RPC-PLUS)?

Can you give an example?

Regards,
Andrey

Matt Mastracci

unread,
Sep 2, 2010, 9:44:21 AM9/2/10
to seas, DotSpots Open Source
Hi Andrey,

gwt-rpc-plus uses an optimized format for the requests that can be serialized directly to and from the JS objects via native JSON or eval/uneval.

The JSON blob you have below is a direct representation of the JS object produced here:

http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plus/gwt/com/dotspots/rpcplus/client/jsonrpc/impl/StandardCallEncoder.java

The corresponding response from the server looks like this:

http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plus/gwt/com/dotspots/rpcplus/client/jsonrpc/CallResponse.java

Note that in the default setup, we also allow some looser JSON encodings to let us cut out some of the time required to serialize these objects. You may want to disallow the looser JSON encoders on the client to allow your code to use standard JSON libraries on the server. This will add some overhead to Firefox versions < 3.1, but simplify your server-side implementation.

seas

unread,
Sep 3, 2010, 2:20:17 AM9/3/10
to DotSpots Open Source
But how to do this? Is it already supported by existing gwt-rpc-plus
codebase?
I see not only the structure of request is different, but, for
example, args also serialized differently, and StandardCallEncoder
does nothing with args serialization format, generated code does. Does
codegen supports some other formats (thrift verbose JSON-based
format)?

Regards,
Andrey

On Sep 2, 5:44 pm, Matt Mastracci <matt...@mastracci.com> wrote:
> Hi Andrey,
>
> gwt-rpc-plus uses an optimized format for the requests that can be serialized directly to and from the JS objects via native JSON or eval/uneval.
>
> The JSON blob you have below is a direct representation of the JS object produced here:
>
> http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plu...
>
> The corresponding response from the server looks like this:
>
> http://code.google.com/p/gwt-rpc-plus/source/browse/trunk/gwt-rpc-plu...

Matt Mastracci (DotSpots)

unread,
Sep 3, 2010, 11:06:11 AM9/3/10
to DotSpots Open Source
Unfortunately the codebase doesn't support other serialization formats
at this time. We use this in production as a way to talk to our own
backends, which are all running the server-side code here.

It may be possible to change the code generator to generate GWT stubs
support the native, verbose Thrift format, but I haven't looked into
that. You'd lose a few advantages of this system, namely a much
smaller request/response size and near-zero impact on your output
code.

The alternative, modifying the server-side codegen to create the
appropriate C++ stubs for this format, might be the same level of
difficulty.

A third (although potentially slower alternative) would be putting a
Java backend between your GWT frontend and C++ backend that translates
between the two. The latency wouldn't be that bad if you were on the
same box.
Reply all
Reply to author
Forward
0 new messages