On Wed, Aug 28, 2013 at 1:58 PM, Thomas Broyer <[email protected]> wrote:
> > > On Wednesday, August 28, 2013 11:37:15 AM UTC+2, Jens wrote: >> >> Isn't that what Cloud Endpoints do already? The problem with both of them >>> is that you cannot write a client for any existing web API, as there are >>> constraints in what you can do. Flatpack also comes with its own protocol >>> (when Cloud Endpoints use JSON-RPC; why do you think there's a JSON-RPC >>> dialect in RequestFactory ;-) ) >>> Disclaimer: I haven't looked at flatpack for a while. >>> >> >> Sure its very similar to Cloud Endpoints. What kind of protocol is used >> is kind of irrelevant. First we need to figure out whats the most easy yet >> flexible approach to support JAX-RS. If the final solution is designed well >> it shouldn't be a problem to make the actual protocol pluggable. >> > > It depends what our goal is. If it's to support arbitrary REST endpoint > (with marshalling, otherwise RequestBuilder or XMLHttpRequest would be > enough), then we're protocol-agnostic besides HTTP. > You could build protocols (RPC, RF, JSON-RPC) on top of it but if you're > going to hide it then why not just use RequestBuilder or even > XMLHttpRequest? > > >> I like what Square did with Retrofit >> http://square.github.**io/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<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. >>> >> >> >> Don't forget iOS. Everything mentioned above are Java/JVM based solutions >> that won't work on iOS. Cloud Endpoints also provides a generator for >> native Objective-C client Api. >> >> https://developers.google.com/**appengine/docs/java/endpoints/** >> consume_ios<https://developers.google.com/appengine/docs/java/endpoints/consume_ios> >> > > But all we need is a generator for GWT from Cloud Endpoints "discovery" > descriptions (and it already exists AFAICT) > > >> There are basically two kinds of situations to support: >> >> 1.) As a company you have a REST/JSON server and want to consume the data >> in various devices in various languages. Everything is under the control of >> the company. The generator (flatpack, Cloud Endpoints) approach would work >> well here. And if the company opens its API for 3rd parties, these 3rd >> parties could also use the generator approach because an API description is >> available that the generator understands. >> >> 2.) You want to consume an existing web API that may or may not have a >> machine readable API description. >> >> In case of 2.) if a machine readable API description is available we >> could make a generator to understand it (probably in a pluggable way). If >> only a API documentation exists (web pages) then a generator can not really >> help unless the developer is willing to write a machine readable API >> description based on the API documentation. >> >> IMHO if GWT provides REST support it should support 1.) and 2.) and not >> just 2.). >> > > There should be support for both, but not necessarily in GWT proper. I > have no idea what the discussions at the pre-I/O meeting were, whether it's > about "replacing GWT-RPC" (possibly being "more RESTful" and less "RPC", > but handling marshalling) and/or having better support for REST (possibly > with pluggable and/or flexible marshalling). > I have been pushing for this in the meetings and in the early roadmap discussions. My main points are: - Provide of a simplistic RPC mechanism that is not locked to a single client tech (i.e. rest / json). - Need to serve common needs but not necessarily solve all problems. - May or may not replace GWT-RPC. - It would be nice to reduce replication if the server interfaces are available (i.e. jax-rs support). For anything else, it is easy to go with a third-party lib. See related this slide<https://docs.google.com/a/google.com/presentation/d/1A-bi5vuhCHs8TqQHRmaSabNjc_5UZeYyJfrzWr8S9oI/edit#slide=id.gc22abae6_020> and this slide<https://docs.google.com/a/google.com/presentation/d/1A-bi5vuhCHs8TqQHRmaSabNjc_5UZeYyJfrzWr8S9oI/edit#slide=id.gc22abae6_041> from the meetup. -- > 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. > -- 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.
