On Wednesday, August 28, 2013 11:36:02 AM UTC+2, John A. Tamplin wrote:
>
> On Wed, Aug 28, 2013 at 4:59 AM, Thomas Broyer <[email protected]<javascript:>
> > wrote:
>
>> I like what Square did with Retrofit http://square.github.io/retrofit/, 
>> which looks a lot like Errai's JAX-RS. The net advantage of Errai's JAX-RS 
>> is that you can simply implement your interface on the server-side and have 
>> the annotations inherited from it. AFAICT this is the same as Resteasy's 
>> proxy framework: 
>> http://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/RESTEasy_Client_Framework.html,
>>  
>> so your client interface could be shared by your GWT client, Android client 
>> (or anything running in a JVM) and server resource (whether Resteasy or 
>> Jersey). Errai's approach to asynchronous calls feels like an ugly hack 
>> too: they absolutely wanted to be able to use the exact same interface 
>> everywhere, when an async interface could be automatically generated from 
>> the synchronous one (e.g. using annotation processors so it works in any 
>> IDE and outside IDEs too). Compare that, for example, to gwt-jsonrpc from 
>> Gerrit, where everything "looks" asynchronous (and the server-side could 
>> possibly be *made* asynchronous with servlets 3).
>> The problem with all of them (Retrofit, JAX-RS, Errai) is how to 
>> configure them (almost everything in Errai shouts “unoptimizable output” 
>> though; Errai puts the focus on the developer's productivity when GWT is 
>> about optimized JS), particularly how you configure such things like 
>> "interceptors" to inject headers or process error responses (e.g. to handle 
>> authentication; probably something similar to the RequestTransport of 
>> RequestFactory, or the RpcRequestBuilder of GWT-RPC) and 
>> marshallers/unmarshallers; and make that configuration "GWT friendly". 
>> Maybe we should wait for the GWT.create() changes.
>>  
>> Using Retrofit has a similar issue to GWT-RPC -- you want your 
> server-side interface to be synchronous, but your client-side interface to 
> be async.
>

Did I say that?! I see Retrofit as client-only (which I believe it is).
That said, I don't think you necessarily want the server-side to be 
synchronous (it could actually be handy to be asynchronous)
 

> So, I don't see a lot of benefit of being able to use the same interface 
> on the client and server because you don't actually want that.  We could 
> certainly have a GWT-RPC-like generator that works with an arbitrary REST 
> API using sync and async interfaces, and we could keep the GWT-specific 
> bits out of the sync interface so that code could easily be "shared" (even 
> though the generator would just verify that they are compatible).
>

The problem with not sharing any code is that you have 2 things (at least) 
to update and maintain in sync. When one can be generated from the other, 
or both can be generated from a definition in whatever format (e.g. 
Protocol Buffer), then that's not a problem though.
The problem with GWT-RPC is that we don't have anything to generate the 
async interface form the sync one (the gwt-maven-plugin has some –broken– 
support, as does the Google Plugin for Eclipse, and possibly the GWT 
support in IntelliJ and/or NetBeans; but an annotation processor would Just 
Work™ –OK, most of the time, it kind of sucks in Eclipse– and would work 
everywhere).
gwt-jsonrpc IMO adopted the most sensible approach without need of a 
generator: async-everywhere (on the server-side, you don't return the 
response, instead you give it to the callback; I believe this has to happen 
synchronously though).

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to