I haven't really looked into gwt-rpc-plus (as its mainly Java), but here are some thoughts 1. Plugging in a generic framework, whose primary goal is to provide a reliable and secure socket (with underlying transports) for all browsers, instead of duplicating the same effort sounds like the best solution to me 2. As easyXDM really only handles the cross-domain communication on the client side, you are free to choose how to communicate back to the server. XHR is the most viable solution, and if used with polling/ long running requests etc., then you could actually support the server pushing data to the client. 3. The meta data (headers, status codes) can easily be transferred together with the serialized data encoded in a JSON object 4. Each easyXDM.Socket/Rpc is bi-directional with the Rpc class correlating messages into a request/response model 5. easyXDM is designed so that new transports (and behaviors) can be added without changing any of the API's. Adding future technologies is not an issue. 6. Why would you need to tailor the core transport mechanism to GWT?
If I had any experience with GWT I would submit a ready-to-use implementation for you (I could find no good sources on how to implement a custom transport), but I don't. So hopefully someone will take the time to do a prototype, or to give me info on how to get started. Sean Kinsey On Mar 22, 6:03 pm, Matt Mastracci <matt...@mastracci.com> wrote: > 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 athttp://easyxdm.net/; > > the Rpc sample can be found > > athttp://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.
