Hi Matt,
I'm just checking out of svn gwt-rpc-plus now. I'm hoping I can use it
to wire up a solution to what seems like a simple problem: I want GWT
to serialize my DTO object and post it to a servlet that will generate
a pdf/excel file/etc for download. The DTOs are numerous / complex
enough
Alex,
We're using this to generate the classes we'll be using for our own
RPC going forward. It won't help you serialize existing DTOs, but it
will offer a shortcut if you want to create a parallel tree of objects
for RPC.
It sounds like the only part that might be relevant to your needs
David,
The new RPC framework in the library currently suffers from the
reference limits of Thrift itself, which are 'no self or forward
references'. This effectively limits the object nesting depth.
Additionally, all the de/serialization is done via native primitives
which seem to
@Matt
I was just wondering if it were possible to specify a concrete substitute
for an interface type - this would this help solve the too many serializer
problem. By too many Serializers i mean of course the need for the
generator to create Serializers for all concrete types implementing List
Miroslav,
This would definitely help (it's actually already filed as
http://code.google.com/p/google-web-toolkit/issues/detail?id=837).
We've been working around this ourselves by creating final subclasses
of all the collections and making sure that we use them for all RPC.
I believe that the
Matthew,
Now you got me interested! I currently have some JSNI code to
communicate between different modules, I would love to take this out
and replace it with something RPC style.
Can your RPC library handle complex structures (where the current 1.x
GWT RPC layers gives stackoverflow or out of
To me this sounds *very* interesting. Makes me want to find out all
the details why GWT-RPC is as it is, if the simpler JS collections
improve upon performance, memory footprint and (permutation) code size
etc. Efforts like this might have a big impact on mobile GWT
applications, which
Bart,
One principle of design for the alternate RPC framework in this
library was reducing the number of non-JSO classes generated in the
final output, at the expense of developer convenience and
flexibility. At one point, RPC classes and serializers were nearing
20% of our compiled
