http://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc.html

I’ve implmented what I think is my ideal client/server communication on another project (non-web). It involved locating all the code and data for the transaction in a single object.

It is implemented something like this:

public MyXferObject extends MyXferObjectBase {
private int x;
private int y;
private int result;

public MyXferObject(int px, int py) {
x=px;
y=py;
}

public arrivedServer() {
result = x + y; // Long complicated operation
}

public arrivedClient() {
aLabel.setText(”The result was:”+result);
}
}

This has a few advantages and some pretty serious problems.

As for the advantages, it keeps everything needed for a given client/server transaction in one file. The shared data makes coding trivial, and there is no need to futz around with specialized interfaces or async callbacks, there are just two methods to override and that’s it–the arrivedServer is executed when the object arrives at the server, and the arrivedClient is executed by what is currently called the callback.

This also makes the calling as simple as “(new MyXferObject(1, 2)).send()” if we assume that the parent class implements a .send method to kick things off.

The disadvantages:
References to classes that exist only on the client or server will not compile on the “other side”.

Twoi possible solutions to this are:
- Pre-compiling to split the class into something that resembles the current RPC mechanism, or
- Using annotations to prevent the errors by specifying methods that shouldn’t compile on one side or the other.

There is also a perceived problem that you are “Mixing” client and server code in the same object, but since the concept is one that actually bridges the client and server, I think it’s completely appropriate.

Besides, the real advantage comes when the client and server portions are implemented separately. One abstract class implements the arrivedServer method–sy it does some generic database I/O, on some data fields. This could later be extended, overriding the “arrivedClient” method and possibly the constructor to set up the data, which should lead to quite a bit more reuse.

What I mean by “more reuse” is that this approach completely isolates and removes the RPC portion of the problem allowing a mid-level portion to be added on top of the communications without re-implementing it every time. I don’t know an easy way to do that with the existing RPC mechanism.

I am kind of working on this right now, and I’m just not familiar with the GWT compiler or annotations so I’m not sure where to start with the first problem I listed, but I’ll keep hacking at it.

Oh, also if this sits on top of the existing RPC mechanism there is the problem that I’ll always be passing a generic object around which the docs said was inefficient. Using a pre-compiler should solve that too.

@Justin: We must be doing a bad job of explaining the full philosophy of GWT. We are most definitely *not* trying to abstract away the web; we’re just trying to add leverage to make better apps possible. That’s why GWT has the JavaScript Native Interface (JSNI), JSON, and XML libraries in addition to GWT-RPC. Widgets are styled with CSS.

If you have the time, please check out the GWT mission statement in “Making GWT Better” (http://code.google.com/webtoolkit/makinggwtbetter.html) to hear the full story. All that said, if we can be doing more to simplify interop or enhance the web user experience, please say so on the GWT contributor fourm.