will deRPC ship with GWT 2.0 ?

[Sami Jaber]

Following a question I asked privately to Bruce and Amit.
Thanks for your response gwitters

Sami

On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson <br...@google.com> wrote:

Sami, would you mind asking this question directly on the Contributors list? We can answer it so that everyone has a chance to comment.

Thanks.

On Sat, Oct 17, 2009 at 1:46 AM, Sami Jaber <sami....@gmail.com> wrote:

Bruce,

What is the status of deRPC API in GWT 2. The code is in the trunk, it seems to be work very well (at least with my test cases) but nothing in GWT MS1 Amit announce and very few gwtc posts regarding the API/issue.

Are you planning to ship deRPC with GWT 2 (I would love to regarding all the JDO/AppEngine integration) ? Similarly, are you planning to update GPE to conform to the new interfaces, RpcService, RpcServlet, etc ... (http://code.google.com/eclipse/docs/gwt_rpc.html) ?

Thanks for you response,

Sami
   

[Bruce Johnson]

So, here's the deal on deRPC. It doesn't yet have the miles on it that we'd like, so we're pretty much on the fence as to whether to really ship it in GWT 2.0 or not.

It has been included in MS1 and will be in MS2, but we may still make a "no go" decision before the GWT 2.0 RC comes out.

If you (as in, anyone reading this email) have tried the new RPC stuff and have feedback, now would be the right time to give it a thumbs up or thumbs down. At the moment, we're leaning thumbs down -- mainly to be conservative.

-- Bruce

[Sami Jaber]

IMHO, It would be a mistake not to make it happen for GWT 2

deRPC is a huge step forward in terms of performance, extensibility, command sinking, serialization extensibility, security and so forth
Everybody know that GWT 2 will introduce new API and many new functionalities, why deRPC would not be part of the show?
Because it has not been intensively tested ? There's probably a lack of tests cases, sure, but it is not specific to deRPC. When I see the last commit streams, deRPC seems to me more reliable than other APIs. And regarding the migration path and the different use case scenarios, this is sweet. If you want to stay in legacy land, just use the straight RemoteServiceServlet class. If you want to support the two modes, just inherits from HybridServiceServlet (as JUnitHostImpl does in the trunk right now). If you are a newcomer, forget all the old non-extensible interfaces and use RpcServlet and RpcService.

Releasing deRPC does not mean that you won't be able to patch if later. Earlier it will be released, earlier you will get feedback. Please think about it.

My 2 french euros,

[Bruce Johnson]

Love the enthusiasm!

Anyone else?

[Sven Brunken]

I also vote for deRPC. I am already using it in many places without
any problems. It has even less problems because of the missing "script
took too long" warning.

I run into one problem so far and that was already listed here:
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/631b8c3177930913/ff6c1c7e5d059a1a?

And what I can say, Mark will also vote for it ;)
We worked together to find the real exception that is occurring in the
posted example (stack overflow due to infinite loop)


Sven Brunken

On 19 Okt., 22:28, Bruce Johnson <br...@google.com> wrote:
> Love the enthusiasm!
> Anyone else?
>

> >> On Mon, Oct 19, 2009 at 3:45 PM, Sami Jaber <sami.ja...@gmail.com> wrote:
>
> >>> Following a question I asked privately to Bruce and Amit.
> >>> Thanks for your response gwitters
>
> >>> Sami
>
> >>> On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson <br...@google.com> wrote:
>
> >>>> Sami, would you mind asking this question directly on the Contributors
> >>>> list? We can answer it so that everyone has a chance to comment.
> >>>> Thanks.
>

[David]

Hi,

Just my opinion, so take my strong statements with a grain of salt as
I have a tendency to see my problems as being the most important in
the world :-) But you were asking for input, right ?

GWT is being pushed as THE tool for AJAX development. The RPC part is
fundamental to the AJAX experience yet it does not scale very well
beyond a Hello World or Twitter client. And for the Twitter client one
could argue that you really need a standard implementation for push
messaging instead.

RPC is really bad with object graphs. If you have a tree or linked
list you don't need a lot of nodes to see it crash with a stack
overflow. Sending larger payloads is also the best way to make the app
stall.

The current RPC is just fundamentally broken in the implementation
that maybe it does not deserve to be in GWT 2.0 either.

I do not see any need to move my code to GWT 2.0 if the RPC is not
fixed. The new UI features are nice to have but not critical to the
applications. The JS optimisations do not make a lot of difference
since our UI's are not really CPU bound. The new widgets or declartive
UI part is nice, but we can do without - a faster table/tree
implementation in the trunk would be very usefull (the incubator seems
to be dead ?) since it is the main reason why people select ExtGWT or
other GWT widget sets (which do not really use GWT the way they
should).

The only thing that is really missing in GWT is a decent RPC that can
be trusted to just work.

David

[Sami Jaber]

Hope that those arguments would not make the difference when you will have to decide. 

Please see my following responses inline :

On Tue, Oct 20, 2009 at 9:24 AM, David <david...@gmail.com> wrote:

 

GWT is being pushed as THE tool for AJAX development. The RPC part is
fundamental to the AJAX experience yet it does not scale very well
beyond a Hello World or Twitter client.

This is a subjective feeling. We build every day mission critical and ERP applications that use GWT and the RPC API without any scalability problem.

Just don't flood your server with large payload requests.

 

And for the Twitter client one
could argue that you really need a standard implementation for push
messaging instead.

 

You can use Comet, there are tons of XMPP implementation (Emite), etc ...

GWT could not support natively all the particularities of every single messaging protocol in the world. If the objective is to cover the scope of the JDK Framework, it won't make it.

gwt-user should stay small and efficient (although I would love to see something like RX Framework http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html).  

 

RPC is really bad with object graphs. If you have a tree or linked
list you don't need a lot of nodes to see it crash with a stack
overflow. Sending larger payloads is also the best way to make the app
stall.

 

Do you have any precise use case or failed test case ? Have you send any issue ? 

We all repeat all the day long that RPC is not RMI and the client side is Javascript. One should avoid to send large payload. 

This is an unfair argument (although  many things can be done in terms of lightweight collections).

 

The current RPC is just fundamentally broken in the implementation
that maybe it does not deserve to be in GWT 2.0 either.

Disagree with that.

 

I do not see any need to move my code to GWT 2.0 if the RPC is not
fixed. The new UI features are nice to have but not critical to the
applications. The JS optimisations do not make a lot of difference
since our UI's are not really CPU bound. The new widgets or declartive
UI part is nice, but we can do without - a faster table/tree
implementation in the trunk would be very usefull (the incubator seems
to be dead ?) since it is the main reason why people select ExtGWT or
other GWT widget sets (which do not really use GWT the way they
should).

Now you are complaining about GWT in general. All the features you point out are huge enhancements. 

CodeSplitting is a great evolution toward better scalability and performance.

GWT has so many things to do that they must prioritize.

Taking into account the foundation (compiler optims, runAsync, performances, browser support, ...)  before creating sexy and flashy widgets framework is just about good sense.  

 

The only thing that is really missing in GWT is a decent RPC that can
be trusted to just work.

What is for you a "decent RPC" ?

 

David

[Mark Goerdes]

As Sven said,

I'm very interested in deRPC. Thumbs up!

Regards,
Mark Gördes

On 19 Okt., 22:56, Sven Brunken <s...@extjs.com> wrote:
> I also vote for deRPC. I am already using it in many places without
> any problems. It has even less problems because of the missing "script
> took too long" warning.
>

> I run into one problem so far and that was already listed here:http://groups.google.com/group/google-web-toolkit-contributors/browse...

[Yegor]

Are there any wiki pages or other docs explaining the deRPC approach
that one can read? Or maybe a list of major classes one could take a
look at?

Specifically, I'm interested in the "much more hackable code base"
mentioned in this post:

http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/631b8c3177930913/6f15dbd5243f10b3

Thanks,

Yegor

On Oct 19, 2:28 pm, Bruce Johnson <br...@google.com> wrote:
> Love the enthusiasm!
> Anyone else?
>

> >> On Mon, Oct 19, 2009 at 3:45 PM, Sami Jaber <sami.ja...@gmail.com> wrote:
>
> >>> Following a question I asked privately to Bruce and Amit.
> >>> Thanks for your response gwitters
>
> >>> Sami
>
> >>> On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson <br...@google.com> wrote:
>
> >>>> Sami, would you mind asking this question directly on the Contributors
> >>>> list? We can answer it so that everyone has a chance to comment.
> >>>> Thanks.
>