Re: GWT RPC in GWT 3.0+

[juan ronquillo]

gRPC has now browser support https://github.com/grpc/grpc-web , Any news 
about GWT-gRPC integration 

On Saturday, February 6, 2016 at 5:54:17 PM UTC-5, Tom Davies wrote:
>
> I'm not actively using GWt at present, unfortunately, but I second the 
> importance of GWT-RPC.
>
> For me the ability to statically type the interfaces is very important, 
> and the tooling support that Intellij IDEA provides makes it easy to use.
>
> Are there any statically typed alternatives? It's a shame that grpc 
> doesn't have browser support.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/28233a61-7fb6-46f2-ab9a-0d92c2437e62%40googlegroups.com.

Re: GWT RPC in GWT 3.0+

[gwtarplayer]

A bit of a long pause but I was busy...

Re:

>> ... But RPC in itself is about making compromises on AJAX use ("obscure" 
payload, asymmetrical payload because they were not meant to be parsed by 
the same tools and in the same environments, everything sent to the URLs, 
etc. all of this make it impractical at best to use RPC along with, for 
example, service workers), and that will eventually degrade the web 
experience for users. Moving away from RPC is actually trading development 
"convenience" for a better user experience.

Development convenience = better developer experience. End-user experience 
has nothing to do with obscure or asymmetrical payloads. That is an 
implementation detail. It is also something that can be changed, improved 
if it needs to be.

Re all recommendations for other frameworks:

Thanks, but many of us are aware of them and they do not solve the problem. 
It is important to note that there are differences in the problems being 
solved by these. One kinds deals with exposing network-accessible APIs to 
3rd part clients. The other kind is *strictly* intended for internal 
communication.

The first generally dictates the API definition first, in some way that can 
be used across versions and with different languages and other 
technologies. None of this is important in the second case. What is 
important is the efficiency of making calls between two parts of the same 
product (client, server). That *very* much so includes developer 
convenience, because they will have more time to work on what matters. 
Furthermore, by focusing on the same language on both ends of the 
connection it becomes possible to actually share code and avoid pitfalls 
that many make when attempting to create their own approaches (even if it 
means using ready-made frameworks - one would have to map language 
features). 

Examples of where GWT RPC *COULD* excel and others fail miserably:

 i)Development convenience - speed of development, more time left for 
what matters.
 
 ii)   Development convenience - less risk of defect due to forgotten 
configuration or otherwise.
 
 iii)  Development convenience - less to learn, quicker to start. No need 
to learn anything new re how to configure/annotate anything to make the 
class serializable.
 
 iv)   Development convenience - shared code - same code can be used 
everywhere, no separation into client and server.
 
 v)Support for cyclic graphs - Object "A" can reference "B" and "B" can 
reference "A". If you send both, you still have two objects to deal with, 
not four or infinity. This *is* important.
 
 vi)   Runtime performance (yes!) - because of (v).
 
 vii)  Runtime performance (yes!) - because developers can rely on highly 
optimized framework implementation that "knows" exactly what is under the 
hood and is not overly generic. It can directly reference generated 
JavaScript code (as obfuscated) as needed and, thus, shorten both payloads 
and execution time.
  
 viii) Works out of box
 
 ix)   Does not need any extra frameworks to be brought in, version 
matched, etc.
 
 x)Can follow (Java) language improvements in step with GWT.
 
 xi)   Emulates more of Java - specifically "Serializable".
 
 xii)  "I can use 3rd party code that does NOT have to know anything about 
the framework I am using and I don't have to teach it anything either". 
 
 xiii) Works with private fields too.
 

Note:

 1. Yes, GWT compiler has to analyze a lot to figure out serialization. But 
so would any other framework that would attempt to do as much. At the same 
time, being a part of the compiler, GWT RPC processing can actually cache a 
lot and significantly shorten the compilation time - base Java and GWT 
libraries do NOT change within the scope of use of a single GWT SDK and 
third party libraries change rarely. Furthermore, it seems to me based on 
observations, that GWT goes over the analysis multiple times (i.e. does not 
cache stuff even in memory, at least in part).
 
 2. Yes, GWT RPC is downright NASTY to apply as it is today. But this can 
be improved greatly. We wrapped it to address that, inside GWT this would 
be easier. For us it is enough to annotate a method of a server class with 
a single annotation to make it appear on the client side, as *that* method, 
in *that* class, without having to (hand-) create any interfaces. We can 
also combine and batch calls - in fact they all go through one single GWT 
RPC method of a single service. For example, if there was a "Server" class 
in the server and it had methods "log(Object)" and 
"getRandomNumberGenerator()", one *could* invoke 
Server.log(Server.getRandomNumberGenerator().generateRandomNumber()) by 
writing exactly that line of code, client or server. Disclaimer: in this 
case the client would not be aware of the end result/success of that. 
Passing an additional AsyncCallback argument to the Server.log(...) call 
would allow for that too - it does in our implementation. Note that this 
approach 

Re: GWT RPC in GWT 3.0+

[JonL]

Agreed, it's all a matter of perspective.  I use GWT-RPC alot, I actually 
don't see anything wrong with the underlying mechanisms, except for the 
SerializationPolicy and its generator.  It's the SerializationPolicy 
generation that is the main culprit for the deficiencies perceived in 
GWT-RPC.  However, I think that they don't have to be part and parcel and 
in GWT 3.0, I would personally like to see them separated and the 
SerializationPolicy made pluggable, instead of ripping out GWT-RPC.  IMO, 
if the Serialization policy generation were made pluggable, then we could 
have different solutions that provide different tradeoffs and GWT devs 
could choose the solution that best suits them.

On Tuesday, July 19, 2016 at 1:34:28 PM UTC-7, clou...@gmail.com wrote:
>
> I was contrasting the blog post to the presentations Ray/Daniel have given 
> in the past, hence the Singular example preceding what you are quoting.  
> These are on youtube and I've also attended their presentations in person.
>
> I'm not trying to argue the compilation efficiency of GWT-RPC or get an 
> explanation of why it is so slow or say there aren't alternatives.  If I am 
> giving off those impressions, I apologize.
>
> I am attempting to point out (poorly I suppose) that the value of the 
> feature largely stems from one's perspective or point of view.  When one 
> uses GWT-RPC, one trades the compile-hit for the functionality.  Similarly 
> with SOYC reports or massive numbers of permutations, you can generate 
> them, however they incur a time/space cost.  These are choices, they have 
> costs, and my point has largely been to let the users decide if the 
> trade-offs fit their needs or not. (Please don't explain how SOYC/Perms 
> don't impact incremental compile!)
>
> Most of the GWT-RPC criticism here (and in the blog post) are purely 
> technical detail about some of its shortcomings and its impact on 
> incremental compile.  From the detailed technical point of view, 
> Daniel/Thomas make accurate observations and there is not much to discuss.  
> However, at the feature level of GWT-RPC, given its flaws/quirks, many 
> folks would still opt to use it in at least some situations with the cost 
> it incurs.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[cloud450]

I was contrasting the blog post to the presentations Ray/Daniel have given 
in the past, hence the Singular example preceding what you are quoting.  
These are on youtube and I've also attended their presentations in person.

I'm not trying to argue the compilation efficiency of GWT-RPC or get an 
explanation of why it is so slow or say there aren't alternatives.  If I am 
giving off those impressions, I apologize.

I am attempting to point out (poorly I suppose) that the value of the 
feature largely stems from one's perspective or point of view.  When one 
uses GWT-RPC, one trades the compile-hit for the functionality.  Similarly 
with SOYC reports or massive numbers of permutations, you can generate 
them, however they incur a time/space cost.  These are choices, they have 
costs, and my point has largely been to let the users decide if the 
trade-offs fit their needs or not. (Please don't explain how SOYC/Perms 
don't impact incremental compile!)

Most of the GWT-RPC criticism here (and in the blog post) are purely 
technical detail about some of its shortcomings and its impact on 
incremental compile.  From the detailed technical point of view, 
Daniel/Thomas make accurate observations and there is not much to discuss.  
However, at the feature level of GWT-RPC, given its flaws/quirks, many 
folks would still opt to use it in at least some situations with the cost 
it incurs.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

That section doesn't touch on "To paraphrase: we have a powerful compiler, let 
it do work for you, you can't get that from ." It 
talks about the fact the mere presence of a class in the compile classpath 
changes the output, and the difficulty of tracking dependencies: add an 
"implements X" to a class and a totally different part of the application could 
"need" to be recompiled (re-generated), just because it references "X" (but not 
the class that was changed). This is not about *whether* to use the compiler 
but rather how to use it efficiently.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[cloud450]

>
> > 
> The compile time argument has me scratching my head. 
>
> I can't find any such argument in Daniel's blog post.
>
"Slow compiles due to global analysis" section. Specifically talks about 
the global knowledge vs incremental compile issue.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

> 
The compile time argument has me scratching my head. 

I can't find any such argument in Daniel's blog post. The problem certainly is 
not compile time vs runtime, it's about global knowledge, scanning the whole 
compile classpath (which is slow) and assuming it'll be similar to the runtime 
classpath: add a JAR to the classpath and see your compiled size blow up. 
Having an @ExtraTypes-like annotation to act as a whitelist would solve this 
and likely allow RPC to be done as an annotation processor.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[cloud450]

We've been using GWT-RPC for a while now as well, and the alternatives 
seemed less desirable the last time I poked around at them.  Reading over 
some of the cited poor choices GWT-RPC, they seem to me to be more like 
"features" and "trade-offs" instead of simply being bad choices.

Version skew is a good example. It's cited as a negative, but in other 
contexts is actually a positive.  The client has outdated information 
regarding the service/model objects? It SHOULD blow up. Old/new 
clients/servers communicating with each other I'm sure is commonplace at 
Google and in it's related applications, however this is absolutely unheard 
of in a static deployment environment, such as in consumer or enterprise 
deployments.  Version skew actually catches deployment errors during 
testing in those situations.

The compile time argument has me scratching my head. I've listened to many 
presentations from Ray/Daniel regarding GWT (big fan, btw). The compiler is 
often cited as what separates GWT from those other JS lib technologies. I 
especially liked Daniel's dig at Angular via Singular, but it was a good 
demonstration of how powerful compile time analytics can trump a runtime 
library. To paraphrase: we have a powerful compiler, let it do work for 
you, you can't get that from .

To cite GWT-RPC as requiring the compiler time-hit that it does strikes me 
as a choice/trade-off, not a negative.  For some applications, it may be a 
"good thing" (tm), but a "bad thing" (tm) in others (see version skew 
above).  To me, this feels like GWT is a little self-conflicted. We have 
this compiler, it could do a lot of work for us, but we don't want it to do 
too much work for us because we want it to be lightning fast!  Maybe I'm 
just old-fashioned, but I'm ok with compilers taking extra time if it 
serves some value/purpose.

While I know there is this great "quest" to speed up GWT compiles such that 
developing in GWT has very little overhead as compared to just regular JS 
development, I would implore that a "carrot" approach is taken over the 
"stick."  If, as a developer, I'm willing take a compile time hit for a 
feature (GWT-RPC or otherwise), seems like having the option would be a 
"good thing", while on the other hand the GWT compilation speed can still 
be lightning fast when we ask less of the compiler by not using such 
features.

On Wednesday, July 13, 2016 at 3:24:14 PM UTC-7, Daniel Kurka wrote:
>
> I summed up what I think about GWT RPC and it's future here:
> http://blog.daniel-kurka.de/2016/07/gwt-rpcs-future.html
>
> On Thu, Jul 14, 2016 at 12:01 AM JonL  > wrote:
>
>> While I agree that it could theoretically work with annotations, 
>> annotations require access to code, so for things you have no control over, 
>> you either would need to implement custom serialization anyways, or use the 
>> GWT serialization.
>>
>> I personally think there are optimizations to be had in the serialization 
>> policy generator that would prevent that whole classpath rescan issue, but 
>> I haven't had a chance to look into the code.
>>
>> If we were to use annotations, I think it would be better to use 
>> annotations on the RPC mechanism.
>>
>> On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>>
>>>
>>>
>>> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>>
>>
 On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
 >
 > Will the gwt serialization mechanism used in GWT-RPC remain? GWT 
 object serialization has been plugged into the atmosphere (realtime 
 communication/websockets) GWT extension. It would be useful to know if we 
 should migrate away from the GWT serialization and towards JSON.

 It's the serialisation that's the problem, so it will be gone in 3.0. 
 JSON is a good choice. (I'm moving that way)

>>>
>>> The actual problem is not serialization per se, it is that the RPC 
>>> generator scans the whole classpath for subclasses of transferred classes 
>>> to generate their specific ser/deser code (taking into account their 
>>> CustomFieldSerializer if one exists).
>>> RPC (thus probably Atmosphere) could be made to work (as annotation 
>>> processors) if they use another mechanism to determine what can be 
>>> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
>>> I believe Daniel Kurka said something along those lines a year ago when 
>>> first talking about those changes. The logical next question is: is there 
>>> anyone willing to make those changes and continue to maintain GWT-RPC? The 
>>> answer seemed to be (have been?) "at least that won't be Google", and this 
>>> is why people start to "panic". That does not mean RPC will be gone (that 
>>> doesn't mean it'll still be there either).
>>> But let's concentrate on 2.8 for now.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To 

Re: GWT RPC in GWT 3.0+

[Ali Jalal]

Thanks Daniel for detailed post about GWT-RPC.

On Thu, Jul 14, 2016 at 1:53 AM, Daniel Kurka 
wrote:

> I summed up what I think about GWT RPC and it's future here:
> http://blog.daniel-kurka.de/2016/07/gwt-rpcs-future.html
>
> On Thu, Jul 14, 2016 at 12:01 AM JonL  wrote:
>
>> While I agree that it could theoretically work with annotations,
>> annotations require access to code, so for things you have no control over,
>> you either would need to implement custom serialization anyways, or use the
>> GWT serialization.
>>
>> I personally think there are optimizations to be had in the serialization
>> policy generator that would prevent that whole classpath rescan issue, but
>> I haven't had a chance to look into the code.
>>
>> If we were to use annotations, I think it would be better to use
>> annotations on the RPC mechanism.
>>
>> On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>>
>>>
>>>
>>> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>>
>>
 On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
 >
 > Will the gwt serialization mechanism used in GWT-RPC remain? GWT
 object serialization has been plugged into the atmosphere (realtime
 communication/websockets) GWT extension. It would be useful to know if we
 should migrate away from the GWT serialization and towards JSON.

 It's the serialisation that's the problem, so it will be gone in 3.0.
 JSON is a good choice. (I'm moving that way)

>>>
>>> The actual problem is not serialization per se, it is that the RPC
>>> generator scans the whole classpath for subclasses of transferred classes
>>> to generate their specific ser/deser code (taking into account their
>>> CustomFieldSerializer if one exists).
>>> RPC (thus probably Atmosphere) could be made to work (as annotation
>>> processors) if they use another mechanism to determine what can be
>>> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
>>> I believe Daniel Kurka said something along those lines a year ago when
>>> first talking about those changes. The logical next question is: is there
>>> anyone willing to make those changes and continue to maintain GWT-RPC? The
>>> answer seemed to be (have been?) "at least that won't be Google", and this
>>> is why people start to "panic". That does not mean RPC will be gone (that
>>> doesn't mean it'll still be there either).
>>> But let's concentrate on 2.8 for now.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> Visit this group at https://groups.google.com/group/google-web-toolkit.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Daniel Kurka]

I summed up what I think about GWT RPC and it's future here:
http://blog.daniel-kurka.de/2016/07/gwt-rpcs-future.html

On Thu, Jul 14, 2016 at 12:01 AM JonL  wrote:

> While I agree that it could theoretically work with annotations,
> annotations require access to code, so for things you have no control over,
> you either would need to implement custom serialization anyways, or use the
> GWT serialization.
>
> I personally think there are optimizations to be had in the serialization
> policy generator that would prevent that whole classpath rescan issue, but
> I haven't had a chance to look into the code.
>
> If we were to use annotations, I think it would be better to use
> annotations on the RPC mechanism.
>
> On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>
>>
>>
>> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>
>>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>>> >
>>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT
>>> object serialization has been plugged into the atmosphere (realtime
>>> communication/websockets) GWT extension. It would be useful to know if we
>>> should migrate away from the GWT serialization and towards JSON.
>>>
>>> It's the serialisation that's the problem, so it will be gone in 3.0.
>>> JSON is a good choice. (I'm moving that way)
>>>
>>
>> The actual problem is not serialization per se, it is that the RPC
>> generator scans the whole classpath for subclasses of transferred classes
>> to generate their specific ser/deser code (taking into account their
>> CustomFieldSerializer if one exists).
>> RPC (thus probably Atmosphere) could be made to work (as annotation
>> processors) if they use another mechanism to determine what can be
>> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
>> I believe Daniel Kurka said something along those lines a year ago when
>> first talking about those changes. The logical next question is: is there
>> anyone willing to make those changes and continue to maintain GWT-RPC? The
>> answer seemed to be (have been?) "at least that won't be Google", and this
>> is why people start to "panic". That does not mean RPC will be gone (that
>> doesn't mean it'll still be there either).
>> But let's concentrate on 2.8 for now.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[JonL]

While I agree that it could theoretically work with annotations, 
annotations require access to code, so for things you have no control over, 
you either would need to implement custom serialization anyways, or use the 
GWT serialization.

I personally think there are optimizations to be had in the serialization 
policy generator that would prevent that whole classpath rescan issue, but 
I haven't had a chance to look into the code.

If we were to use annotations, I think it would be better to use 
annotations on the RPC mechanism.

On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>
>
>
> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>>
>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  
>> wrote:
>> >
>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
>> serialization has been plugged into the atmosphere (realtime 
>> communication/websockets) GWT extension. It would be useful to know if we 
>> should migrate away from the GWT serialization and towards JSON.
>>
>> It's the serialisation that's the problem, so it will be gone in 3.0. 
>> JSON is a good choice. (I'm moving that way)
>>
>
> The actual problem is not serialization per se, it is that the RPC 
> generator scans the whole classpath for subclasses of transferred classes 
> to generate their specific ser/deser code (taking into account their 
> CustomFieldSerializer if one exists).
> RPC (thus probably Atmosphere) could be made to work (as annotation 
> processors) if they use another mechanism to determine what can be 
> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
> I believe Daniel Kurka said something along those lines a year ago when 
> first talking about those changes. The logical next question is: is there 
> anyone willing to make those changes and continue to maintain GWT-RPC? The 
> answer seemed to be (have been?) "at least that won't be Google", and this 
> is why people start to "panic". That does not mean RPC will be gone (that 
> doesn't mean it'll still be there either).
> But let's concentrate on 2.8 for now.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Vassilis Virvilis]

just a side note on this

Although GWT-RPC is the easy low threshold for someone coming from the java
world SOAP, RMI (like me) two things that didn't fly well were:

1) GWT-RPC favors overspecifying the collection type. So it is better to
say ArrayList > List > Collection in your interfaces.

2) It was difficult to share server side code without including GWT
specific jars. So I had to create proxies for my SOAP services which was
problematic. With Resty-GWT at least my server code can have multiple types
of clients js, java, GWT etc.

   Vassilis

On Wed, Jul 13, 2016 at 7:23 PM, Thomas Broyer  wrote:

>
>
> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>>
>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>> >
>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object
>> serialization has been plugged into the atmosphere (realtime
>> communication/websockets) GWT extension. It would be useful to know if we
>> should migrate away from the GWT serialization and towards JSON.
>>
>> It's the serialisation that's the problem, so it will be gone in 3.0.
>> JSON is a good choice. (I'm moving that way)
>>
>
> The actual problem is not serialization per se, it is that the RPC
> generator scans the whole classpath for subclasses of transferred classes
> to generate their specific ser/deser code (taking into account their
> CustomFieldSerializer if one exists).
> RPC (thus probably Atmosphere) could be made to work (as annotation
> processors) if they use another mechanism to determine what can be
> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
> I believe Daniel Kurka said something along those lines a year ago when
> first talking about those changes. The logical next question is: is there
> anyone willing to make those changes and continue to maintain GWT-RPC? The
> answer seemed to be (have been?) "at least that won't be Google", and this
> is why people start to "panic". That does not mean RPC will be gone (that
> doesn't mean it'll still be there either).
> But let's concentrate on 2.8 for now.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>
>
> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
> >
> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
> serialization has been plugged into the atmosphere (realtime 
> communication/websockets) GWT extension. It would be useful to know if we 
> should migrate away from the GWT serialization and towards JSON.
>
> It's the serialisation that's the problem, so it will be gone in 3.0. JSON 
> is a good choice. (I'm moving that way)
>

The actual problem is not serialization per se, it is that the RPC 
generator scans the whole classpath for subclasses of transferred classes 
to generate their specific ser/deser code (taking into account their 
CustomFieldSerializer if one exists).
RPC (thus probably Atmosphere) could be made to work (as annotation 
processors) if they use another mechanism to determine what can be 
transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
I believe Daniel Kurka said something along those lines a year ago when 
first talking about those changes. The logical next question is: is there 
anyone willing to make those changes and continue to maintain GWT-RPC? The 
answer seemed to be (have been?) "at least that won't be Google", and this 
is why people start to "panic". That does not mean RPC will be gone (that 
doesn't mean it'll still be there either).
But let's concentrate on 2.8 for now.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Paul Robinson]

On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>
> Will the gwt serialization mechanism used in GWT-RPC remain? GWT object
serialization has been plugged into the atmosphere (realtime
communication/websockets) GWT extension. It would be useful to know if we
should migrate away from the GWT serialization and towards JSON.

It's the serialisation that's the problem, so it will be gone in 3.0. JSON
is a good choice. (I'm moving that way)

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Kay Pac]

Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
serialization has been plugged into the atmosphere (realtime 
communication/websockets) GWT extension. It would be useful to know if we 
should migrate away from the GWT serialization and towards JSON.

On Thursday, July 7, 2016 at 3:53:18 AM UTC-7, Thomas Broyer wrote:
>
>
>
> On Thursday, July 7, 2016 at 11:54:11 AM UTC+2, Philippe Gonze wrote:
>>
>> Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the 
>> current GWT developpers,
>>
>> For me GWT is "Web development based on Java expertise, with practically 
>> no other technology implications". Extremely powerful and pleasant. Seems 
>> that GWT 3.0 is announced as "no more GWT":
>>
>
> From http://www.gwtproject.org/makinggwtbetter.html: “GWT’s mission is to 
> radically improve the web experience for users by enabling developers to 
> use existing Java tools to build no-compromise AJAX for any modern browser.”
> Also pay attention to what GWT is NOT about.
> GWT 3.0 as described in this thread would still follow this mission 
> statement.
> Providing tools to do RPC, even if differently than today, would still 
> follow the design axioms. But RPC in itself is about making compromises on 
> AJAX use ("obscure" payload, asymmetrical payload because they were not 
> meant to be parsed by the same tools and in the same environments, 
> everything sent to the URLs, etc. all of this make it impractical at best 
> to use RPC along with, for example, service workers), and that will 
> eventually degrade the web experience for users. Moving away from RPC is 
> actually trading development "convenience" for a better user experience.
>  
>
>> Our plan will probably to stay with 2.8...
>>
>
> And this is exactly why GWT 2.x and GWT 3 are expected to coexist for a 
> while.
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Chad Vincent]

Hey, speak for yourself.  ;)

RMI is awesome for prototyping or when the networking aspects are a 
secondary feature where performance isn't an issue.  Maybe better off as a 
library, but still useful.

On Saturday, July 9, 2016 at 6:02:23 PM UTC-5, Hristo Stoyanov wrote:
>
> Gwt-rpc had siMilar fate as RMI in java - it was cute idea at first, but 
> we wish it was not in modern java...

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Hristo Stoyanov]

Gwt-rpc had siMilar fate as RMI in java - it was cute idea at first, but we 
wish it was not in modern java...

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Mark Erikson]

I built an app using GWT and GWT-RPC in 2011-2012, but am currently working 
on a clean-slate rewrite of the client using modern JS (ES6, React, 
Webpack, etc).  I've opted to leave the existing client codebase entirely 
as-is, and have exposed my existing backend APIs over JSON-RPC as well.  
This is allowing me to make some pretty good progress on the new client 
without having to make significant changes to the backend or the existing 
client.  It's also very nice to finally be able to examine my network calls 
in a browser debugger, and since JSON-RPC is language-independent, would 
also make it feasible to call those APIs in other contexts if I ever wanted 
to.

On Thursday, July 7, 2016 at 2:17:12 PM UTC-4, Gilberto wrote:
>
> When I first used GWT, I started using GWT RPC as the main communication 
> channel with the server. Years later, when I first needed a native mobile 
> application, and when I needed to expose API endpoints to partners to 
> integrate data with my services, I realized I should have gone RESTful from 
> day 1 - migrating from GWT RPC to a RESTful architecture was painful and 
> slow.
>
> GWT RPC is easy to implement and close to other Java communication 
> technologies (like RMI), but in my experience can create several problems 
> in the long term.
>
> Having said that, I'm always ok with options. GWT won't support GWT RPC in 
> the future, but nothing stops anyone from porting the current GWT RPC 
> mechanism to GWT 3. Of course several stuff would need to change (because 
> of the generators), but I'd imagine it's totally doable.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Gilberto]

When I first used GWT, I started using GWT RPC as the main communication 
channel with the server. Years later, when I first needed a native mobile 
application, and when I needed to expose API endpoints to partners to 
integrate data with my services, I realized I should have gone RESTful from 
day 1 - migrating from GWT RPC to a RESTful architecture was painful and 
slow.

GWT RPC is easy to implement and close to other Java communication 
technologies (like RMI), but in my experience can create several problems 
in the long term.

Having said that, I'm always ok with options. GWT won't support GWT RPC in 
the future, but nothing stops anyone from porting the current GWT RPC 
mechanism to GWT 3. Of course several stuff would need to change (because 
of the generators), but I'd imagine it's totally doable.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Velusamy Velu]

I have developed a few GWT applications but never used the RPC. I didn't 
feel comfortable using RemoveService, RemoteServiceServlet, and ServiceDef; 
it reminded me the days of CORBA and IDL. I have been staying with 
extending the RequestCallback.

On Thursday, July 7, 2016 at 5:54:11 AM UTC-4, Philippe Gonze wrote:
>
> Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the 
> current GWT developpers,
>
> For me GWT is "Web development based on Java expertise, with practically 
> no other technology implications". Extremely powerful and pleasant. Seems 
> that GWT 3.0 is announced as "no more GWT":
>
> Our plan will probably to stay with 2.8... But will 2.8 ever be released 
> ??? Developers have been waiting for it for so long... GWT's communication 
> is very strange and paradoyal.
>
>
>
>
> Le vendredi 5 février 2016 10:59:02 UTC+1, gwtar...@gmail.com a écrit :
>>
>> I understand that the future of GWT RPC does not seem bright in 3.0+ but 
>> I want to express my opinion that this is a HUGE mistake. GWT RPC is one of 
>> the most important things in GWT as it truly ties things together in large 
>> apps. Sure, it its raw form it is a bit cumbersome to use but it enables 
>> true code reuse with no extra coding. This is what sets GWT apart from the 
>> run-of-the-mill frameworks out there. Creating custom requests and 
>> responses is not maintainable and scalable in a large app that depends on 
>> extensibility and polymorphism. Ability to communicate almost any Java 
>> object graph without having to specifically annotate or declare anything, 
>> while preserving singletons is a huge advantage.
>>
>> Sure, it lacks a lot of things. We used it with out proprietary wrapper 
>> framework in a way that allows us to simply annotate sever-side methods we 
>> want to expose to the client and everything else is automagically handled - 
>> the client gains the visibility into relevant server classes and methods 
>> with same signatures other than getting results asynchronously. One can 
>> pass results of some method call as an argument of another all without 
>> leaving the sever and without having to wire boilerplate/weird code.For 
>> example, if we had the following code on the server
>>
>>   public class Foo {
>> public static Bar getBar() {
>>   return new Bar();
>> }
>> public static String someText() {
>>   return "Blah: " + System.currentTimeMillis();
>> }
>>   }
>>   public class Bar {
>> public String twice(String text) {
>>   return text + text;
>> }
>>   }
>>   
>> 
>>
>>  with our annotations on the server (not shown) the following client 
>> code would be possible:
>>
>>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>>  ...
>>  public void onSuccess(String result) { 
>>...
>>  }
>>}
>>
>> ... no need for creating server + async interfaces, etc.
>>
>> With every other alternative we lose on simplicity and ability to 
>> communicate. All others require us to create more client-server 
>> communication code which we have been able to avoid.
>>
>> Needless to say, we'd be stuck in pre-3.0 land as we have a large code 
>> investment in GWT RPC - we could not accept losing it... but we do want to 
>> go to the newest GWT at any time. It would be greatly disappointing if we 
>> couldn't do this.
>>
>> I do not see the advantages of losing RPC. It does what it does better 
>> than anything else out there and is irreplaceable.
>>
>> Please do not get rid of it. Enhance it. It is what makes GWT better than 
>> the rest. It is what, together with the rest, allows seamless and uniform 
>> language use across the client and the server. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

On Thursday, July 7, 2016 at 11:54:11 AM UTC+2, Philippe Gonze wrote:
>
> Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the 
> current GWT developpers,
>
> For me GWT is "Web development based on Java expertise, with practically 
> no other technology implications". Extremely powerful and pleasant. Seems 
> that GWT 3.0 is announced as "no more GWT":
>

>From http://www.gwtproject.org/makinggwtbetter.html: “GWT’s mission is to 
radically improve the web experience for users by enabling developers to 
use existing Java tools to build no-compromise AJAX for any modern browser.”
Also pay attention to what GWT is NOT about.
GWT 3.0 as described in this thread would still follow this mission 
statement.
Providing tools to do RPC, even if differently than today, would still 
follow the design axioms. But RPC in itself is about making compromises on 
AJAX use ("obscure" payload, asymmetrical payload because they were not 
meant to be parsed by the same tools and in the same environments, 
everything sent to the URLs, etc. all of this make it impractical at best 
to use RPC along with, for example, service workers), and that will 
eventually degrade the web experience for users. Moving away from RPC is 
actually trading development "convenience" for a better user experience.
 

> Our plan will probably to stay with 2.8...
>

And this is exactly why GWT 2.x and GWT 3 are expected to coexist for a 
while.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Philippe Gonze]

Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the 
current GWT developpers,

For me GWT is "Web development based on Java expertise, with practically no 
other technology implications". Extremely powerful and pleasant. Seems that 
GWT 3.0 is announced as "no more GWT":

Our plan will probably to stay with 2.8... But will 2.8 ever be released 
??? Developers have been waiting for it for so long... GWT's communication 
is very strange and paradoyal.




Le vendredi 5 février 2016 10:59:02 UTC+1, gwtar...@gmail.com a écrit :
>
> I understand that the future of GWT RPC does not seem bright in 3.0+ but I 
> want to express my opinion that this is a HUGE mistake. GWT RPC is one of 
> the most important things in GWT as it truly ties things together in large 
> apps. Sure, it its raw form it is a bit cumbersome to use but it enables 
> true code reuse with no extra coding. This is what sets GWT apart from the 
> run-of-the-mill frameworks out there. Creating custom requests and 
> responses is not maintainable and scalable in a large app that depends on 
> extensibility and polymorphism. Ability to communicate almost any Java 
> object graph without having to specifically annotate or declare anything, 
> while preserving singletons is a huge advantage.
>
> Sure, it lacks a lot of things. We used it with out proprietary wrapper 
> framework in a way that allows us to simply annotate sever-side methods we 
> want to expose to the client and everything else is automagically handled - 
> the client gains the visibility into relevant server classes and methods 
> with same signatures other than getting results asynchronously. One can 
> pass results of some method call as an argument of another all without 
> leaving the sever and without having to wire boilerplate/weird code.For 
> example, if we had the following code on the server
>
>   public class Foo {
> public static Bar getBar() {
>   return new Bar();
> }
> public static String someText() {
>   return "Blah: " + System.currentTimeMillis();
> }
>   }
>   public class Bar {
> public String twice(String text) {
>   return text + text;
> }
>   }
>   
> 
>
>  with our annotations on the server (not shown) the following client 
> code would be possible:
>
>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>  ...
>  public void onSuccess(String result) { 
>...
>  }
>}
>
> ... no need for creating server + async interfaces, etc.
>
> With every other alternative we lose on simplicity and ability to 
> communicate. All others require us to create more client-server 
> communication code which we have been able to avoid.
>
> Needless to say, we'd be stuck in pre-3.0 land as we have a large code 
> investment in GWT RPC - we could not accept losing it... but we do want to 
> go to the newest GWT at any time. It would be greatly disappointing if we 
> couldn't do this.
>
> I do not see the advantages of losing RPC. It does what it does better 
> than anything else out there and is irreplaceable.
>
> Please do not get rid of it. Enhance it. It is what makes GWT better than 
> the rest. It is what, together with the rest, allows seamless and uniform 
> language use across the client and the server. 
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Vassilis Virvilis]

While I agree that static typing is of great importance I fail to see how
this is a unique feature of GWT-RPC. I believe all alternatives suggested
by people in this thread are statically typed.

On Sun, Feb 7, 2016 at 12:54 AM, Tom Davies  wrote:

> I'm not actively using GWt at present, unfortunately, but I second the
> importance of GWT-RPC.
>
> For me the ability to statically type the interfaces is very important,
> and the tooling support that Intellij IDEA provides makes it easy to use.
>
> Are there any statically typed alternatives? It's a shame that grpc
> doesn't have browser support.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Tom Davies]

I'm not actively using GWt at present, unfortunately, but I second the 
importance of GWT-RPC.

For me the ability to statically type the interfaces is very important, and 
the tooling support that Intellij IDEA provides makes it easy to use.

Are there any statically typed alternatives? It's a shame that grpc doesn't 
have browser support.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[David]

Will the RequestBuilder API remain ?


On Fri, Feb 5, 2016 at 9:36 PM Ed  wrote:

> RestyGWT is one of the options. Another less mentioned is the low level
> RequestBuilder.  We moved to RB due to the large number of fields we are
> managing (400+) and use json on the client to consume the requests.
>
> Ed
>
> On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis 
> wrote:
>
>> I have successfully ported a medium API (~30 methods) from GWT-RPC to
>> Resty-GWT. While everybody's case is unique it went surprisingly well for
>> me (as far as transitions go).
>>
>> 1) The big advantage is that although you can use RestyGWT with a
>> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself
>> with the new API design of the Restful tomorrow word.
>>
>> 2) Another advantage for me was that I had already a WS stack (CXF) and
>> thus with GWT-RPC I was either reimplementing my CXF services or I was
>> proxying them.
>>
>> 3) By ditching GWT-RPC I was able to free myself from server side code.
>>
>> 4) It is now easier to work with standard json and json inspection tools
>> like console.log(object_received) and with browser's network inspection
>> tools
>>
>> 5) RestyGWT has a async interface in order to keep your familiar GWT-RPC
>> handlers so the changes in the code are minimal. What takes more work is to
>> ensure that all your object's are transmitted correctly over the wire. This
>> is not walk in the park but for simple objects it just works. For more
>> complex cases you may need to implement a Provider or something.
>>
>> 6) I don't know about your special @annotations that somehow remove the
>> need to specify interface + async_interface but for me this is a major
>> plus. The client code does not need to link to server definitions and for
>> me API is something that changes with great difficulty and rarely. So wher
>> API breaks I am editing both files - I don't mind.
>>
>>  Vassilis
>>
>>
>> On Fri, Feb 5, 2016 at 4:16 AM,  wrote:
>>
>>> I understand that the future of GWT RPC does not seem bright in 3.0+ but
>>> I want to express my opinion that this is a HUGE mistake. GWT RPC is one of
>>> the most important things in GWT as it truly ties things together in large
>>> apps. Sure, it its raw form it is a bit cumbersome to use but it enables
>>> true code reuse with no extra coding. This is what sets GWT apart from the
>>> run-of-the-mill frameworks out there. Creating custom requests and
>>> responses is not maintainable and scalable in a large app that depends on
>>> extensibility and polymorphism. Ability to communicate almost any Java
>>> object graph without having to specifically annotate or declare anything,
>>> while preserving singletons is a huge advantage.
>>>
>>> Sure, it lacks a lot of things. We used it with out proprietary wrapper
>>> framework in a way that allows us to simply annotate sever-side methods we
>>> want to expose to the client and everything else is automagically handled -
>>> the client gains the visibility into relevant server classes and methods
>>> with same signatures other than getting results asynchronously. One can
>>> pass results of some method call as an argument of another all without
>>> leaving the sever and without having to wire boilerplate/weird code.For
>>> example, if we had the following code on the server
>>>
>>>   public class Foo {
>>> public static Bar getBar() {
>>>   return new Bar();
>>> }
>>> public static String someText() {
>>>   return "Blah: " + System.currentTimeMillis();
>>> }
>>>   }
>>>   public class Bar {
>>> public String twice(String text) {
>>>   return text + text;
>>> }
>>>   }
>>>
>>>
>>>
>>>  with our annotations on the server (not shown) the following client
>>> code would be possible:
>>>
>>>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>>>  ...
>>>  public void onSuccess(String result) {
>>>...
>>>  }
>>>}
>>>
>>> ... no need for creating server + async interfaces, etc.
>>>
>>> With every other alternative we lose on simplicity and ability to
>>> communicate. All others require us to create more client-server
>>> communication code which we have been able to avoid.
>>>
>>> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
>>> investment in GWT RPC - we could not accept losing it... but we do want to
>>> go to the newest GWT at any time. It would be greatly disappointing if we
>>> couldn't do this.
>>>
>>> I do not see the advantages of losing RPC. It does what it does better
>>> than anything else out there and is irreplaceable.
>>>
>>> Please do not get rid of it. Enhance it. It is what makes GWT better
>>> than the rest. It is what, together with the rest, allows seamless and
>>> uniform language use across the client and the server.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Users" group.
>>> To 

Re: GWT RPC in GWT 3.0+

[Alain Ekambi]

Does not it rely on xmlhttp request which uses jsni ?
On 6 Feb 2016 18:55, "Thomas Broyer"  wrote:

> There's no reason it couldn't: does not use generator nor JSNI.
>
> On Saturday, February 6, 2016 at 11:08:15 AM UTC+1, DavidN wrote:
>>
>> Will the RequestBuilder API remain ?
>>
>>
>> On Fri, Feb 5, 2016 at 9:36 PM Ed  wrote:
>>
>>> RestyGWT is one of the options. Another less mentioned is the low level
>>> RequestBuilder.  We moved to RB due to the large number of fields we are
>>> managing (400+) and use json on the client to consume the requests.
>>>
>>> Ed
>>>
>>> On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis 
>>> wrote:
>>>
 I have successfully ported a medium API (~30 methods) from GWT-RPC to
 Resty-GWT. While everybody's case is unique it went surprisingly well for
 me (as far as transitions go).

 1) The big advantage is that although you can use RestyGWT with a
 procedural SOAP logic (like GWT-RPC) you can start familiarize yourself
 with the new API design of the Restful tomorrow word.

 2) Another advantage for me was that I had already a WS stack (CXF) and
 thus with GWT-RPC I was either reimplementing my CXF services or I was
 proxying them.

 3) By ditching GWT-RPC I was able to free myself from server side code.

 4) It is now easier to work with standard json and json inspection
 tools like console.log(object_received) and with browser's network
 inspection tools

 5) RestyGWT has a async interface in order to keep your familiar
 GWT-RPC handlers so the changes in the code are minimal. What takes more
 work is to ensure that all your object's are transmitted correctly over the
 wire. This is not walk in the park but for simple objects it just works.
 For more complex cases you may need to implement a Provider or something.

 6) I don't know about your special @annotations that somehow remove the
 need to specify interface + async_interface but for me this is a major
 plus. The client code does not need to link to server definitions and for
 me API is something that changes with great difficulty and rarely. So wher
 API breaks I am editing both files - I don't mind.

  Vassilis


 On Fri, Feb 5, 2016 at 4:16 AM,  wrote:

> I understand that the future of GWT RPC does not seem bright in 3.0+
> but I want to express my opinion that this is a HUGE mistake. GWT RPC is
> one of the most important things in GWT as it truly ties things together 
> in
> large apps. Sure, it its raw form it is a bit cumbersome to use but it
> enables true code reuse with no extra coding. This is what sets GWT apart
> from the run-of-the-mill frameworks out there. Creating custom requests 
> and
> responses is not maintainable and scalable in a large app that depends on
> extensibility and polymorphism. Ability to communicate almost any Java
> object graph without having to specifically annotate or declare anything,
> while preserving singletons is a huge advantage.
>
> Sure, it lacks a lot of things. We used it with out proprietary
> wrapper framework in a way that allows us to simply annotate sever-side
> methods we want to expose to the client and everything else is
> automagically handled - the client gains the visibility into relevant
> server classes and methods with same signatures other than getting results
> asynchronously. One can pass results of some method call as an argument of
> another all without leaving the sever and without having to wire
> boilerplate/weird code.For example, if we had the following code on the
> server
>
>   public class Foo {
> public static Bar getBar() {
>   return new Bar();
> }
> public static String someText() {
>   return "Blah: " + System.currentTimeMillis();
> }
>   }
>   public class Bar {
> public String twice(String text) {
>   return text + text;
> }
>   }
>
>
>
>  with our annotations on the server (not shown) the following
> client code would be possible:
>
>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>  ...
>  public void onSuccess(String result) {
>...
>  }
>}
>
> ... no need for creating server + async interfaces, etc.
>
> With every other alternative we lose on simplicity and ability to
> communicate. All others require us to create more client-server
> communication code which we have been able to avoid.
>
> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
> investment in GWT RPC - we could not accept losing it... but we do want to
> go to the newest GWT at any time. It would be greatly disappointing if we

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

There's no reason it couldn't: does not use generator nor JSNI.

On Saturday, February 6, 2016 at 11:08:15 AM UTC+1, DavidN wrote:
>
> Will the RequestBuilder API remain ?
>
>
> On Fri, Feb 5, 2016 at 9:36 PM Ed  wrote:
>
>> RestyGWT is one of the options. Another less mentioned is the low level 
>> RequestBuilder.  We moved to RB due to the large number of fields we are 
>> managing (400+) and use json on the client to consume the requests.
>>
>> Ed
>>
>> On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis  
>> wrote:
>>
>>> I have successfully ported a medium API (~30 methods) from GWT-RPC to 
>>> Resty-GWT. While everybody's case is unique it went surprisingly well for 
>>> me (as far as transitions go).
>>>
>>> 1) The big advantage is that although you can use RestyGWT with a 
>>> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself 
>>> with the new API design of the Restful tomorrow word.
>>>
>>> 2) Another advantage for me was that I had already a WS stack (CXF) and 
>>> thus with GWT-RPC I was either reimplementing my CXF services or I was 
>>> proxying them.
>>>
>>> 3) By ditching GWT-RPC I was able to free myself from server side code.
>>>
>>> 4) It is now easier to work with standard json and json inspection tools 
>>> like console.log(object_received) and with browser's network inspection 
>>> tools
>>>
>>> 5) RestyGWT has a async interface in order to keep your familiar GWT-RPC 
>>> handlers so the changes in the code are minimal. What takes more work is to 
>>> ensure that all your object's are transmitted correctly over the wire. This 
>>> is not walk in the park but for simple objects it just works. For more 
>>> complex cases you may need to implement a Provider or something.
>>>
>>> 6) I don't know about your special @annotations that somehow remove the 
>>> need to specify interface + async_interface but for me this is a major 
>>> plus. The client code does not need to link to server definitions and for 
>>> me API is something that changes with great difficulty and rarely. So wher 
>>> API breaks I am editing both files - I don't mind.
>>>
>>>  Vassilis
>>>
>>>
>>> On Fri, Feb 5, 2016 at 4:16 AM,  wrote:
>>>
 I understand that the future of GWT RPC does not seem bright in 3.0+ 
 but I want to express my opinion that this is a HUGE mistake. GWT RPC is 
 one of the most important things in GWT as it truly ties things together 
 in 
 large apps. Sure, it its raw form it is a bit cumbersome to use but it 
 enables true code reuse with no extra coding. This is what sets GWT apart 
 from the run-of-the-mill frameworks out there. Creating custom requests 
 and 
 responses is not maintainable and scalable in a large app that depends on 
 extensibility and polymorphism. Ability to communicate almost any Java 
 object graph without having to specifically annotate or declare anything, 
 while preserving singletons is a huge advantage.

 Sure, it lacks a lot of things. We used it with out proprietary wrapper 
 framework in a way that allows us to simply annotate sever-side methods we 
 want to expose to the client and everything else is automagically handled 
 - 
 the client gains the visibility into relevant server classes and methods 
 with same signatures other than getting results asynchronously. One can 
 pass results of some method call as an argument of another all without 
 leaving the sever and without having to wire boilerplate/weird code.For 
 example, if we had the following code on the server

   public class Foo {
 public static Bar getBar() {
   return new Bar();
 }
 public static String someText() {
   return "Blah: " + System.currentTimeMillis();
 }
   }
   public class Bar {
 public String twice(String text) {
   return text + text;
 }
   }
   
 

  with our annotations on the server (not shown) the following 
 client code would be possible:

Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
  ...
  public void onSuccess(String result) { 
...
  }
}

 ... no need for creating server + async interfaces, etc.

 With every other alternative we lose on simplicity and ability to 
 communicate. All others require us to create more client-server 
 communication code which we have been able to avoid.

 Needless to say, we'd be stuck in pre-3.0 land as we have a large code 
 investment in GWT RPC - we could not accept losing it... but we do want to 
 go to the newest GWT at any time. It would be greatly disappointing if we 
 couldn't do this.

 I do not see the advantages of losing RPC. It does what it does better 
 than anything else out there and is irreplaceable.

 Please do 

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

Yes, but XMLHttpRequest is a thin wrapper that can easily be replaced with 
JsInterop.
(it also uses a Timer, which uses JSNI, that can also easily be replaced 
with JsInterop)

On Saturday, February 6, 2016 at 6:59:33 PM UTC+1, Alain wrote:
>
> Does not it rely on xmlhttp request which uses jsni ?
> On 6 Feb 2016 18:55, "Thomas Broyer"  wrote:
>
>> There's no reason it couldn't: does not use generator nor JSNI.
>>
>> On Saturday, February 6, 2016 at 11:08:15 AM UTC+1, DavidN wrote:
>>>
>>> Will the RequestBuilder API remain ?
>>>
>>>
>>> On Fri, Feb 5, 2016 at 9:36 PM Ed  wrote:
>>>
 RestyGWT is one of the options. Another less mentioned is the low level 
 RequestBuilder.  We moved to RB due to the large number of fields we are 
 managing (400+) and use json on the client to consume the requests.

 Ed

 On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis  
 wrote:

> I have successfully ported a medium API (~30 methods) from GWT-RPC to 
> Resty-GWT. While everybody's case is unique it went surprisingly well for 
> me (as far as transitions go).
>
> 1) The big advantage is that although you can use RestyGWT with a 
> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself 
> with the new API design of the Restful tomorrow word.
>
> 2) Another advantage for me was that I had already a WS stack (CXF) 
> and thus with GWT-RPC I was either reimplementing my CXF services or I 
> was 
> proxying them.
>
> 3) By ditching GWT-RPC I was able to free myself from server side code.
>
> 4) It is now easier to work with standard json and json inspection 
> tools like console.log(object_received) and with browser's network 
> inspection tools
>
> 5) RestyGWT has a async interface in order to keep your familiar 
> GWT-RPC handlers so the changes in the code are minimal. What takes more 
> work is to ensure that all your object's are transmitted correctly over 
> the 
> wire. This is not walk in the park but for simple objects it just works. 
> For more complex cases you may need to implement a Provider or something.
>
> 6) I don't know about your special @annotations that somehow remove 
> the need to specify interface + async_interface but for me this is a 
> major 
> plus. The client code does not need to link to server definitions and for 
> me API is something that changes with great difficulty and rarely. So 
> wher 
> API breaks I am editing both files - I don't mind.
>
>  Vassilis
>
>
> On Fri, Feb 5, 2016 at 4:16 AM,  wrote:
>
>> I understand that the future of GWT RPC does not seem bright in 3.0+ 
>> but I want to express my opinion that this is a HUGE mistake. GWT RPC is 
>> one of the most important things in GWT as it truly ties things together 
>> in 
>> large apps. Sure, it its raw form it is a bit cumbersome to use but it 
>> enables true code reuse with no extra coding. This is what sets GWT 
>> apart 
>> from the run-of-the-mill frameworks out there. Creating custom requests 
>> and 
>> responses is not maintainable and scalable in a large app that depends 
>> on 
>> extensibility and polymorphism. Ability to communicate almost any Java 
>> object graph without having to specifically annotate or declare 
>> anything, 
>> while preserving singletons is a huge advantage.
>>
>> Sure, it lacks a lot of things. We used it with out proprietary 
>> wrapper framework in a way that allows us to simply annotate sever-side 
>> methods we want to expose to the client and everything else is 
>> automagically handled - the client gains the visibility into relevant 
>> server classes and methods with same signatures other than getting 
>> results 
>> asynchronously. One can pass results of some method call as an argument 
>> of 
>> another all without leaving the sever and without having to wire 
>> boilerplate/weird code.For example, if we had the following code on the 
>> server
>>
>>   public class Foo {
>> public static Bar getBar() {
>>   return new Bar();
>> }
>> public static String someText() {
>>   return "Blah: " + System.currentTimeMillis();
>> }
>>   }
>>   public class Bar {
>> public String twice(String text) {
>>   return text + text;
>> }
>>   }
>>   
>> 
>>
>>  with our annotations on the server (not shown) the following 
>> client code would be possible:
>>
>>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>>  ...
>>  public void onSuccess(String result) { 
>>...
>>  }
>>}
>>
>> ... no need for creating server + async 

Re: GWT RPC in GWT 3.0+

[Tom Davies]

I didn't realise that RestyGWT did the server side too -- thanks for 
getting me to look at it again!

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Tom Davies]

On Sunday, 7 February 2016 18:07:12 UTC+11, Vassilis Virvilis wrote:
>
> AFAIK RestyGWT does not include a server component. You have to rely on 
> another jax-rs server-side stack in order to serve RestyGWT requests.
>
> Here is a list of java implementations although nobody forces to stay on 
> java server side 
> https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services
>

I mean that it allows the same interface to be used to specify the client 
and the server -- see "Reusing server interfaces" at the bottom of this 
page: https://resty-gwt.github.io/documentation/restygwt-user-guide.html

When I say that I want an RPC implementation to be statically typed, I mean 
that the Java type system must enforce that the GWT client matches the 
server implementation, and that if I change either I will get compile time 
errors. This can be done either via Java or via some intermediate 
specification language, I don't mind.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Vassilis Virvilis]

AFAIK RestyGWT does not include a server component. You have to rely on
another jax-rs server-side stack in order to serve RestyGWT requests.

Here is a list of java implementations although nobody forces to stay on
java server side
https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services

On Sun, Feb 7, 2016 at 4:02 AM, Tom Davies  wrote:

> I didn't realise that RestyGWT did the server side too -- thanks for
> getting me to look at it again!
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Ramesh Selvaraj]

Dear All,

 Please any one let me know Where can I download GWT-3.0 package


Ramesh

On Sat, Feb 6, 2016 at 4:36 AM, Ed  wrote:

> RestyGWT is one of the options. Another less mentioned is the low level
> RequestBuilder.  We moved to RB due to the large number of fields we are
> managing (400+) and use json on the client to consume the requests.
>
> Ed
>
> On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis 
> wrote:
>
>> I have successfully ported a medium API (~30 methods) from GWT-RPC to
>> Resty-GWT. While everybody's case is unique it went surprisingly well for
>> me (as far as transitions go).
>>
>> 1) The big advantage is that although you can use RestyGWT with a
>> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself
>> with the new API design of the Restful tomorrow word.
>>
>> 2) Another advantage for me was that I had already a WS stack (CXF) and
>> thus with GWT-RPC I was either reimplementing my CXF services or I was
>> proxying them.
>>
>> 3) By ditching GWT-RPC I was able to free myself from server side code.
>>
>> 4) It is now easier to work with standard json and json inspection tools
>> like console.log(object_received) and with browser's network inspection
>> tools
>>
>> 5) RestyGWT has a async interface in order to keep your familiar GWT-RPC
>> handlers so the changes in the code are minimal. What takes more work is to
>> ensure that all your object's are transmitted correctly over the wire. This
>> is not walk in the park but for simple objects it just works. For more
>> complex cases you may need to implement a Provider or something.
>>
>> 6) I don't know about your special @annotations that somehow remove the
>> need to specify interface + async_interface but for me this is a major
>> plus. The client code does not need to link to server definitions and for
>> me API is something that changes with great difficulty and rarely. So wher
>> API breaks I am editing both files - I don't mind.
>>
>>  Vassilis
>>
>>
>> On Fri, Feb 5, 2016 at 4:16 AM,  wrote:
>>
>>> I understand that the future of GWT RPC does not seem bright in 3.0+ but
>>> I want to express my opinion that this is a HUGE mistake. GWT RPC is one of
>>> the most important things in GWT as it truly ties things together in large
>>> apps. Sure, it its raw form it is a bit cumbersome to use but it enables
>>> true code reuse with no extra coding. This is what sets GWT apart from the
>>> run-of-the-mill frameworks out there. Creating custom requests and
>>> responses is not maintainable and scalable in a large app that depends on
>>> extensibility and polymorphism. Ability to communicate almost any Java
>>> object graph without having to specifically annotate or declare anything,
>>> while preserving singletons is a huge advantage.
>>>
>>> Sure, it lacks a lot of things. We used it with out proprietary wrapper
>>> framework in a way that allows us to simply annotate sever-side methods we
>>> want to expose to the client and everything else is automagically handled -
>>> the client gains the visibility into relevant server classes and methods
>>> with same signatures other than getting results asynchronously. One can
>>> pass results of some method call as an argument of another all without
>>> leaving the sever and without having to wire boilerplate/weird code.For
>>> example, if we had the following code on the server
>>>
>>>   public class Foo {
>>> public static Bar getBar() {
>>>   return new Bar();
>>> }
>>> public static String someText() {
>>>   return "Blah: " + System.currentTimeMillis();
>>> }
>>>   }
>>>   public class Bar {
>>> public String twice(String text) {
>>>   return text + text;
>>> }
>>>   }
>>>
>>>
>>>
>>>  with our annotations on the server (not shown) the following client
>>> code would be possible:
>>>
>>>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>>>  ...
>>>  public void onSuccess(String result) {
>>>...
>>>  }
>>>}
>>>
>>> ... no need for creating server + async interfaces, etc.
>>>
>>> With every other alternative we lose on simplicity and ability to
>>> communicate. All others require us to create more client-server
>>> communication code which we have been able to avoid.
>>>
>>> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
>>> investment in GWT RPC - we could not accept losing it... but we do want to
>>> go to the newest GWT at any time. It would be greatly disappointing if we
>>> couldn't do this.
>>>
>>> I do not see the advantages of losing RPC. It does what it does better
>>> than anything else out there and is irreplaceable.
>>>
>>> Please do not get rid of it. Enhance it. It is what makes GWT better
>>> than the rest. It is what, together with the rest, allows seamless and
>>> uniform language use across the client and the server.
>>>
>>> --
>>> You received this message because you are subscribed to the 

Re: GWT RPC in GWT 3.0+

[Ed]

RestyGWT is one of the options. Another less mentioned is the low level
RequestBuilder.  We moved to RB due to the large number of fields we are
managing (400+) and use json on the client to consume the requests.

Ed

On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis  wrote:

> I have successfully ported a medium API (~30 methods) from GWT-RPC to
> Resty-GWT. While everybody's case is unique it went surprisingly well for
> me (as far as transitions go).
>
> 1) The big advantage is that although you can use RestyGWT with a
> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself
> with the new API design of the Restful tomorrow word.
>
> 2) Another advantage for me was that I had already a WS stack (CXF) and
> thus with GWT-RPC I was either reimplementing my CXF services or I was
> proxying them.
>
> 3) By ditching GWT-RPC I was able to free myself from server side code.
>
> 4) It is now easier to work with standard json and json inspection tools
> like console.log(object_received) and with browser's network inspection
> tools
>
> 5) RestyGWT has a async interface in order to keep your familiar GWT-RPC
> handlers so the changes in the code are minimal. What takes more work is to
> ensure that all your object's are transmitted correctly over the wire. This
> is not walk in the park but for simple objects it just works. For more
> complex cases you may need to implement a Provider or something.
>
> 6) I don't know about your special @annotations that somehow remove the
> need to specify interface + async_interface but for me this is a major
> plus. The client code does not need to link to server definitions and for
> me API is something that changes with great difficulty and rarely. So wher
> API breaks I am editing both files - I don't mind.
>
>  Vassilis
>
>
> On Fri, Feb 5, 2016 at 4:16 AM,  wrote:
>
>> I understand that the future of GWT RPC does not seem bright in 3.0+ but
>> I want to express my opinion that this is a HUGE mistake. GWT RPC is one of
>> the most important things in GWT as it truly ties things together in large
>> apps. Sure, it its raw form it is a bit cumbersome to use but it enables
>> true code reuse with no extra coding. This is what sets GWT apart from the
>> run-of-the-mill frameworks out there. Creating custom requests and
>> responses is not maintainable and scalable in a large app that depends on
>> extensibility and polymorphism. Ability to communicate almost any Java
>> object graph without having to specifically annotate or declare anything,
>> while preserving singletons is a huge advantage.
>>
>> Sure, it lacks a lot of things. We used it with out proprietary wrapper
>> framework in a way that allows us to simply annotate sever-side methods we
>> want to expose to the client and everything else is automagically handled -
>> the client gains the visibility into relevant server classes and methods
>> with same signatures other than getting results asynchronously. One can
>> pass results of some method call as an argument of another all without
>> leaving the sever and without having to wire boilerplate/weird code.For
>> example, if we had the following code on the server
>>
>>   public class Foo {
>> public static Bar getBar() {
>>   return new Bar();
>> }
>> public static String someText() {
>>   return "Blah: " + System.currentTimeMillis();
>> }
>>   }
>>   public class Bar {
>> public String twice(String text) {
>>   return text + text;
>> }
>>   }
>>
>>
>>
>>  with our annotations on the server (not shown) the following client
>> code would be possible:
>>
>>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>>  ...
>>  public void onSuccess(String result) {
>>...
>>  }
>>}
>>
>> ... no need for creating server + async interfaces, etc.
>>
>> With every other alternative we lose on simplicity and ability to
>> communicate. All others require us to create more client-server
>> communication code which we have been able to avoid.
>>
>> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
>> investment in GWT RPC - we could not accept losing it... but we do want to
>> go to the newest GWT at any time. It would be greatly disappointing if we
>> couldn't do this.
>>
>> I do not see the advantages of losing RPC. It does what it does better
>> than anything else out there and is irreplaceable.
>>
>> Please do not get rid of it. Enhance it. It is what makes GWT better than
>> the rest. It is what, together with the rest, allows seamless and uniform
>> language use across the client and the server.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> Visit this 

GWT RPC in GWT 3.0+

[gwtarplayer]

I understand that the future of GWT RPC does not seem bright in 3.0+ but I 
want to express my opinion that this is a HUGE mistake. GWT RPC is one of 
the most important things in GWT as it truly ties things together in large 
apps. Sure, it its raw form it is a bit cumbersome to use but it enables 
true code reuse with no extra coding. This is what sets GWT apart from the 
run-of-the-mill frameworks out there. Creating custom requests and 
responses is not maintainable and scalable in a large app that depends on 
extensibility and polymorphism. Ability to communicate almost any Java 
object graph without having to specifically annotate or declare anything, 
while preserving singletons is a huge advantage.

Sure, it lacks a lot of things. We used it with out proprietary wrapper 
framework in a way that allows us to simply annotate sever-side methods we 
want to expose to the client and everything else is automagically handled - 
the client gains the visibility into relevant server classes and methods 
with same signatures other than getting results asynchronously. One can 
pass results of some method call as an argument of another all without 
leaving the sever and without having to wire boilerplate/weird code.For 
example, if we had the following code on the server

  public class Foo {
public static Bar getBar() {
  return new Bar();
}
public static String someText() {
  return "Blah: " + System.currentTimeMillis();
}
  }
  public class Bar {
public String twice(String text) {
  return text + text;
}
  }
  


 with our annotations on the server (not shown) the following client 
code would be possible:

   Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
 ...
 public void onSuccess(String result) { 
   ...
 }
   }

... no need for creating server + async interfaces, etc.

With every other alternative we lose on simplicity and ability to 
communicate. All others require us to create more client-server 
communication code which we have been able to avoid.

Needless to say, we'd be stuck in pre-3.0 land as we have a large code 
investment in GWT RPC - we could not accept losing it... but we do want to 
go to the newest GWT at any time. It would be greatly disappointing if we 
couldn't do this.

I do not see the advantages of losing RPC. It does what it does better than 
anything else out there and is irreplaceable.

Please do not get rid of it. Enhance it. It is what makes GWT better than 
the rest. It is what, together with the rest, allows seamless and uniform 
language use across the client and the server. 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Vassilis Virvilis]

I have successfully ported a medium API (~30 methods) from GWT-RPC to
Resty-GWT. While everybody's case is unique it went surprisingly well for
me (as far as transitions go).

1) The big advantage is that although you can use RestyGWT with a
procedural SOAP logic (like GWT-RPC) you can start familiarize yourself
with the new API design of the Restful tomorrow word.

2) Another advantage for me was that I had already a WS stack (CXF) and
thus with GWT-RPC I was either reimplementing my CXF services or I was
proxying them.

3) By ditching GWT-RPC I was able to free myself from server side code.

4) It is now easier to work with standard json and json inspection tools
like console.log(object_received) and with browser's network inspection
tools

5) RestyGWT has a async interface in order to keep your familiar GWT-RPC
handlers so the changes in the code are minimal. What takes more work is to
ensure that all your object's are transmitted correctly over the wire. This
is not walk in the park but for simple objects it just works. For more
complex cases you may need to implement a Provider or something.

6) I don't know about your special @annotations that somehow remove the
need to specify interface + async_interface but for me this is a major
plus. The client code does not need to link to server definitions and for
me API is something that changes with great difficulty and rarely. So wher
API breaks I am editing both files - I don't mind.

 Vassilis


On Fri, Feb 5, 2016 at 4:16 AM,  wrote:

> I understand that the future of GWT RPC does not seem bright in 3.0+ but I
> want to express my opinion that this is a HUGE mistake. GWT RPC is one of
> the most important things in GWT as it truly ties things together in large
> apps. Sure, it its raw form it is a bit cumbersome to use but it enables
> true code reuse with no extra coding. This is what sets GWT apart from the
> run-of-the-mill frameworks out there. Creating custom requests and
> responses is not maintainable and scalable in a large app that depends on
> extensibility and polymorphism. Ability to communicate almost any Java
> object graph without having to specifically annotate or declare anything,
> while preserving singletons is a huge advantage.
>
> Sure, it lacks a lot of things. We used it with out proprietary wrapper
> framework in a way that allows us to simply annotate sever-side methods we
> want to expose to the client and everything else is automagically handled -
> the client gains the visibility into relevant server classes and methods
> with same signatures other than getting results asynchronously. One can
> pass results of some method call as an argument of another all without
> leaving the sever and without having to wire boilerplate/weird code.For
> example, if we had the following code on the server
>
>   public class Foo {
> public static Bar getBar() {
>   return new Bar();
> }
> public static String someText() {
>   return "Blah: " + System.currentTimeMillis();
> }
>   }
>   public class Bar {
> public String twice(String text) {
>   return text + text;
> }
>   }
>
>
>
>  with our annotations on the server (not shown) the following client
> code would be possible:
>
>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>  ...
>  public void onSuccess(String result) {
>...
>  }
>}
>
> ... no need for creating server + async interfaces, etc.
>
> With every other alternative we lose on simplicity and ability to
> communicate. All others require us to create more client-server
> communication code which we have been able to avoid.
>
> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
> investment in GWT RPC - we could not accept losing it... but we do want to
> go to the newest GWT at any time. It would be greatly disappointing if we
> couldn't do this.
>
> I do not see the advantages of losing RPC. It does what it does better
> than anything else out there and is irreplaceable.
>
> Please do not get rid of it. Enhance it. It is what makes GWT better than
> the rest. It is what, together with the rest, allows seamless and uniform
> language use across the client and the server.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: GWT RPC in GWT 3.0+

[David]

I always had a love/hate relation with GWT-RPC. I loved it that indeed it
allowed you to quickly add remote calls.

But in bigger applications many of its restrictions started to have a big
impact.
For example it was a pain to do proper integration or performance testing
with GWT-RPC services since they can change with any build. The
serialisation cost was another issue for me. GWT-RPC gave the impression
that any java serialisable object tree can be serialised, but in reality
you better avoid sending deeply nested graphs because the performance was
terrible. So in the end I had to start optimising the object structure and
do some reconstruction at the client side.

I moved to RestGWT now. This is really easy to use as well, even easier. I
just annotate JAXRS services on the server and the client can consume this
without any code replication. I don't need an async api. By using pure REST
api's I can now easily integrate different clients with the same interface.





On Fri, Feb 5, 2016 at 10:57 AM  wrote:

> I understand that the future of GWT RPC does not seem bright in 3.0+ but I
> want to express my opinion that this is a HUGE mistake. GWT RPC is one of
> the most important things in GWT as it truly ties things together in large
> apps. Sure, it its raw form it is a bit cumbersome to use but it enables
> true code reuse with no extra coding. This is what sets GWT apart from the
> run-of-the-mill frameworks out there. Creating custom requests and
> responses is not maintainable and scalable in a large app that depends on
> extensibility and polymorphism. Ability to communicate almost any Java
> object graph without having to specifically annotate or declare anything,
> while preserving singletons is a huge advantage.
>
> Sure, it lacks a lot of things. We used it with out proprietary wrapper
> framework in a way that allows us to simply annotate sever-side methods we
> want to expose to the client and everything else is automagically handled -
> the client gains the visibility into relevant server classes and methods
> with same signatures other than getting results asynchronously. One can
> pass results of some method call as an argument of another all without
> leaving the sever and without having to wire boilerplate/weird code.For
> example, if we had the following code on the server
>
>   public class Foo {
> public static Bar getBar() {
>   return new Bar();
> }
> public static String someText() {
>   return "Blah: " + System.currentTimeMillis();
> }
>   }
>   public class Bar {
> public String twice(String text) {
>   return text + text;
> }
>   }
>
>
>
>  with our annotations on the server (not shown) the following client
> code would be possible:
>
>Foo.getBar().twice(Foo.someText(), new AsyncCallback() {
>  ...
>  public void onSuccess(String result) {
>...
>  }
>}
>
> ... no need for creating server + async interfaces, etc.
>
> With every other alternative we lose on simplicity and ability to
> communicate. All others require us to create more client-server
> communication code which we have been able to avoid.
>
> Needless to say, we'd be stuck in pre-3.0 land as we have a large code
> investment in GWT RPC - we could not accept losing it... but we do want to
> go to the newest GWT at any time. It would be greatly disappointing if we
> couldn't do this.
>
> I do not see the advantages of losing RPC. It does what it does better
> than anything else out there and is irreplaceable.
>
> Please do not get rid of it. Enhance it. It is what makes GWT better than
> the rest. It is what, together with the rest, allows seamless and uniform
> language use across the client and the server.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.