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 is the Thrift support, but you'll need to do the grunt work of writing IDL for the existing classes (or writing your own code generator to do the same). Let me know if it turns out to be useful for you, or if there's something we can add to the library to enable an alternate solution. Matt. On 12-Aug-09, at 3:17 AM, Alex Bertram wrote: > > > 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 that writing some kind parallel serializer is prohibitive. Have > you come across this use case before ? > > Thanks, > > Alex > > On Aug 8, 8:53 pm, Matt Mastracci <[email protected]> wrote: >> 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 output. >> >> By reducing some of the flexibility of RPC (ie, with machine built >> overlay types and collections that implement just enough to get by), >> we can effectively reduce the RPC footprint in terms of wire size, >> code size and serialization/deserialization time. >> >> Note that bobv's direct-eval RPC branch should come with its own >> significant performance gains and code/wire size reductions. It may >> be >> worth investigating the performance of trunk for your specific case >> as >> well. Of course, if GWT RPC is sufficient for your use, you can >> always use this library to add cross-domain transport of RPC payloads >> or add out-of-band context to the request/response data. >> >> I'd be interested in hearing any thoughts or suggestions you might >> have. >> >> Thanks, >> >> Matt. >> >> On 2009-08-08, at 10:16 AM, Bart Guijt <[email protected]> wrote: >> >>> 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 are my primary interest. >> >>> Checking the sources out right now :-) >> >>> Bart Guijt >>> E: [email protected] >>> T: +31 6 30408987 >> >>> Check out my blog:http://bart.guijt.me/blog/ >> >>> "A pizza with the radius 'z' and thickness 'a' has the volume >>> pi*z*z*a" >> >>> On 8 aug 2009, at 8 aug, 04:58, Matt Mastracci wrote: >> >>>> Hey all, >> >>>> We've been working on a number of RPC enhancements locally and >>>> thought >>>> that it might be helpful to open-source some of them (prompted by a >>>> recent suggestion from Ray Cromwell). I've created a new Google >>>> Code >>>> project that encapsulates them here: >> >>>> http://code.google.com/p/gwt-rpc-plus/ >> >>>> It's an umbrella project for a number of RPC enhancements that >>>> we're >>>> using. It includes a set of building blocks and some higher-level >>>> code that builds on them to enhance the current GWT RPC >>>> functionality: >> >>>> 1. A set of 'bare-metal', strongly-typed JS collections optimized >>>> for >>>> both RPC and client-side use. These collections are designed to >>>> mimic >>>> (but not fully support) the interfaces of the standard Java List, >>>> Map >>>> and Set. They are code-generated and based on JavaScriptObject >>>> (see >>>> here:http://code.google.com/p/gwt-rpc-plus/source/browse/#svn/ >>>> trunk/ >>>> gwt-rpc-plus/gwt/com/dotspots/rpcplus/client/jscollections). They >>>> are >>>> essential to the Thrift RPC system (mentioned below), but are >>>> useful >>>> as their own standalone collections. >>>> 2. Alternative JSON and text transports, including a cross-domain >>>> transport using window.name and standard XMLHttpRequest >>>> communication. >>>> 3. A set of fast utility classes to parse and emit JSON using >>>> browser- >>>> native code where possible (ie: JSON.parse/stringify, eval/uneval). >>>> 4. A way to plug alternative transports into GWT RPC (based on a >>>> technique similar to >>>> this:http://timepedia.blogspot.com/2009/04/gwt-rpc-over-arbitrary-transpor >>>> ... >>>> ) >>>> . It currently includes a way to easily replace the RPC transport >>>> with any text transport (including the window.name transport >>>> mentioned >>>> above). >>>> 5. A Thrift-based, versioned RPC framework that can replace GWT >>>> RPC >>>> entirely (built on top of the above-mentioned pieces). >> >>>> The code in the library was extracted from a bunch of code >>>> scattered >>>> throughout our project. I'm still working on refactoring and >>>> cleaning >>>> up parts of it, so it's likely to change over the next few weeks. >>>> None of the architecture is set in stone, so anyone interested in >>>> helping contribute/architect is welcome to join in. >> >>>> Thanks! >>>> Matt. > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
