Re: [gwt-contrib] Proposal for including easyXDM as a new cross-domain Transport/RPC

[Matt Mastracci]

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  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  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
>

Re: [gwt-contrib] Proposal for including easyXDM as a new cross-domain Transport/RPC

[Joel Webber]

[+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  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.

[gwt-contrib] Proposal for including easyXDM as a new cross-domain Transport/RPC

[Sean Kinsey]

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.