Callbacks vs. blocking in the API

[Rob Heittman]

This question comes up in the context of the Google Web Toolkit extension
and thinking about "GWT-Restlet" as a Restlet-API-oriented alternative to
the GWT-REST API (see issue #127,
http://restlet.tigris.org/issues/show_bug.cgi?id=127).

Google Web Toolkit compiles Java to Javascript and runs it in the context of
a Web browser.  In this context, only one type of Client is of critical
import, the XmlHttpRequest facility provided by the browser.  This is
typically an asynchronous mechanism.  While it is possible (in most
browsers) to use the XmlHttpRequest in a blocking way, it's neither
idiomatic nor desirable in most cases.  The mechanisms built into GWT are
all very callback-driven, and GWT-REST echoes this design.

I'm interested in thoughts on the best way to deal with this in Restlet -- I
really have no idea which way to jump here.

So if the Restlet idiom is:

Client client = new Client(Protocol.HTTP);
Response response = client.handle(request);
if (response.getStatus().isSuccess()) {
  System.out.println("Hurray");
}

do we want to try to ensure that this works in "GWT-Restlet" by blocking at
client.handle(request), or do we want to provide something in the callback
style, like

Client client = new Client(Protocol.HTTP);
Response response = client.handleCallback(request, response, new
UniformCallback(){
   void handle(Request request,Response response){
     if (response.getStatus().isSuccess()) {
       System.out.println("Hurray");
     }
   }
});

Or yet another approach, which I have no notion of as yet ...

Thanks for any ideas!

- Rob