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 handle larger structures well.
You don't necessarily have to use Thrift here. I do have some old code (which hasn't been imported here yet unfortunately) that generate client side API stubs that can receive standard API calls made by other client code. I'll dig it up and unrot it. I had completely forgotten about that code until now. By pairing the code with a cross module transport (function call, postMessage or location hash), you'll be able to communicate between two modules using code that looks identical to standard RPC. On 2009-08-09, at 11:56 PM, David <[email protected]> wrote: > > 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 memory) ? > > David > >> Note that we'll be doing some cool stuff with our library in the >> future that we can't easily do with GWT RPC, like generating raw >> Javascript bindings for third-party developers to interface with our >> API and using it for module-to-module cross-domain communication. >> >> On Aug 9, 1:00 am, Miroslav Pokorny <[email protected]> >> wrote: >>> @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 >>> etc. >>> >>> Service { >>> >>> @Annotation(java.util.ArrayList.class); >>> List<Type> method( int parameter ); >>> >>> } >>> >>> In the above case no matter what type of List the server sent, the >>> client >>> would always get an ArrayList. >>> >>> Naturally the same annotation would appear on value types with List >>> properties. Perhaps something similar could be used to whitelist >>> sub class >>> serializer generation. >>> >>> Comments ? >>> >>> On Sun, Aug 9, 2009 at 4:53 AM, 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. >>> >>> -- >>> mP >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
