Quickly browsing easyXDM and comparing to gwt-rpc-plus, it looks like the designs of both are very similar. easyXDM uses the term 'socket' where gwt-rpc-plus uses the term 'transport'. Both of them allow you to plug in the appropriate transport behind a socket-like interface. easyXDM adds some interesting additional functionality like automatic reliability and fragmenting.
I believe that the current transport-focused interface used in both of these libraries is too limited to deal with some of the future technologies coming out of the HTML5 camp and too inflexible to deal with the use cases outside of being a dumb transport client for an RPC server somewhere else. I think that it would be beneficial to the GWT community if whatever transport layer makes it into GWT starts from the drawing board. Here's a brain-dump of some of the issues facing anyone attempting to tackle a generic transport library: 1. Unless a transport explicitly provides send and receive channels internally (ie: XMLHttpRequest), it's best to keep it as separate Sender/Receiver interfaces. There are a number of places where it's useful to compose two different transports (ie: see the next item - POST to send, postMessage to receive). This also allows you to handle inter-window RPC where requests come in through a receive channel and are sent back out over a send channel. 2. The best way I've found to deal with a cross-domain transport in HTML is to do a POST to a hidden <iframe> or ActiveXObject which either uses postMessage or window.name to send back its result. This transport needs to switch at runtime between the two methods: many of the browsers shipping today have supported versions out that don't do postMessage. Additionally, window.name won't be supported in modern browsers in the future: the spec mandates that it gets cleared during cross-domain navigation. 3. Channel metadata is very important to expose to clients. In the case of HTTP, this includes status codes and headers. In the case of postMessage, this includes the message domain and the sending window. In some cases you'll want to tunnel that metadata overtop of another transport via JSON. For instance, when you have a background page in a Chrome extension that accepts events over Chrome's internal messaging and converts them into XMLHttpRequest events to work around the cross-domain restrictions, you'll want to get back something equivalent to having done the RPC directly yourself. 4. Some transports send live JSON objects, while others send text. In the case of web workers, some (but not all) browsers will automatically parse and instantiate JSON on the receiving end if it's sent in that form, while others will accept the JSON objects and emit them as strings on the receiving end. 5. Some send/receive pairs of channels correlate messages internally, while others have no concept of correlation. In gwt-rpc-plus, correlation is managed internally by each transport, but it would be a lot cleaner if there was something you could layer on top of a send and receive channel that turns it into a bidirectional channel with message correlation. 6. There are some interesting transport concepts that need to be validated against any design. For instance: the W3C's crazy MessageChannel spec requires both a half post-message transport (a sender or receiver to send a port reference) and a sender/receiver pair for the entangled channel. Matt. On 2010-03-22, at 8:42 AM, Joel Webber wrote: > [+matt] > > I can't speak to any experience with either of these libraries, but this also > sounds like the work Matt's been doing here: > http://code.google.com/p/gwt-rpc-plus/ > > Can anyone speak to the relationship between these libraries? I'd love to see > a standard way of dealing with XDM make it into the GWT core. > > On Sun, Mar 21, 2010 at 10:59 AM, Sean Kinsey <okin...@gmail.com> wrote: > I've seen many questions on the net on how to enable cross-domain > requests with GWT, and most of the solutions I've seen mentioned has > been less efficient than what I know the easyXDM library can offer. > > For those who has never heard of it, easyXDM is a library that > conveniently abstracts away all the hassle of hash/fragments, > window.name and postMessage, and that exposes a simple and reliable > Socket that allows strings to be passed between two documents (no > reloads, so both documents can keep state). > Whatever kind of transport being used internally (based on what the > browser offers etc) the stack will provide _reliability_, queuing (and > fragmenting if necessary) and security. > > Whats interesting with the library is that it also contains an Rpc > class, that allows you to invoke methods, with complex arguments > (JSON), and with or without return values. > > From the consumers calling an RPC method is as easy as doing > //set up rpc object, only a few simple lines > var rpc = new easyXDM.Rpc(... > > > rpc.nameOfMethod(arg1, arg2, arg3, function > methodToHandleResponse(response){ > ... > }); > > > Why don't you give it a try? > The library has several easy to follow examples at http://easyxdm.net/; > the Rpc sample can be found at > http://consumer.easyxdm.net/current/example/methods.html > > Regards > Sean Kinsey > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > To unsubscribe from this group, send email to > google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this > email with the words "REMOVE ME" as the subject. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.