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 <miroslav.poko...@gmail.com>
> 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 <matt...@mastracci.com>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 <bgu...@gmail.com> 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: bgu...@gmail.com
>> > > 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
-~----------~----~----~----~------~----~------~--~---
