[json-rpc] easyXDM, a cross-domain RPC implementation using JSON-RPC

[Sean Kinsey]

I just wanted to inform you about the easyXDM library(http://
easyxdm.net), a library that enables cross-domain RPC between two
between two loaded HTML documents. The library uses a protocol almost
identical to JSON-PRC, and will shortly be brought more in line with
the spec.

You can take a look at http://easyxdm.net/wp/2010/03/17/remote-procedure-calls-rpc/
to read more about using the easyXDM.Rpc class, or you could skip
right to one of the demos http://easyxdm.net/current/example/methods.html.

The underlying transport supports the use of several different stacks,
FIM (Fragment Identifier Messaging), window.name and postMessage.
All transports are reliable (even the FIM), supports queuing and
fragmenting, and enforces sender-verification.

One of the current demos, showing cross-domain XHR (http://
consumer.easyxdm.net/example/xhr.html) displays the use of the generic
XMLHttpRequest RPC interface, that enables cross-domain ajax, and one
of the ideas I have is to extend this so that it can talk to a generic
JSON-RPC server using HTTP.
The end result would be to be able to expose a JSON-RPC-over-HTTP-
enabled server with very little code.
Does anyone have any suggestions for this, or wish to contribute? The
code that would need extending, or that would be best used as a base
is the current xhr.html document, http://github.com/oyvindkinsey/easyXDM/blob/master/src/xhr.html
.

To show you an example for how the xhr sample is used:

//the following is the code needed to expose an interface usable for
AJAX
var new easyXDM.Rpc({
local: "name.html"
}, {
local: {
post: {
isAsync: true,
method: function(url, data, fn){
// You really should add some filtering to only allow
certain url's
var xhrObj = createXMLHTTPObject();
xhrObj.onreadystatechange = function(){
if (xhrObj.readyState === 4 && xhrObj.status ===
200) {
fn(JSON.parse(xhrObj.responseText));
}
};
xhrObj.open('POST', url, true);
xhrObj.setRequestHeader('Content-Type', 'application/x-
www-form-urlencoded');
var encodedData =
easyXDM.Url.appendQueryParameters("", data).substring(1);
xhrObj.send(encodedData);
}
}
}
});

//and here is the code needed to 'connect' with this from a different
domain
var xhr = new easyXDM.Rpc({
local: "../name.html",
remote: remoteUrl + "/../xhr.html",
remoteHelper: remoteUrl + "/../name.html";
}, {
remote: {
post: {}
}
});


//to make a request you use the following code
xhr.post("example/glossary.php", {
param1: "",
param2: "";
}, function(json){
alert(json.glossary.title);
});

pretty much like any standard ajax function, only that it is cross-
domain!

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Matt (MPCM)]

Looks interesting, the cross-domain stuff is always fun.

Separately, does anyone know why the "You received this message"
signature is now appearing in posts on the newsgroup? I know it makes
sense when it hits your inbox, but it seems odd to have it appear when
accessing the posts through groups.google.com.

--
Matt (MPCM)

[Sean Kinsey]

On Apr 16, 11:06 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> Looks interesting, the cross-domain stuff is always fun.

I just committed changes that brought it inline with JSON-RPC
( http://github.com/oyvindkinsey/easyXDM/blob/master/src/stack/RpcBehavior.js
)
It supports positional arguments for now.

>
> Separately, does anyone know why the "You received this message"
> signature is now appearing in posts on the newsgroup? I know it makes
> sense when it hits your inbox, but it seems odd to have it appear when
> accessing the posts through groups.google.com.

Well, it is part of the message body, and as the body is plain text
there is no meta data to distinguish it from the main part.
It would be inconsistent (and error prone) if it were to try to remove
it when displaying through the web interface.

[Ivan Zuzak]

Looks cool, Sean!

You should also check out pmrpc, a JS library that does basically the
same thing - HTML5 inter-window and web workers remote procedure call
library (uses JSON-RPC as message format). http://code.google.com/p/pmrpc/

Ivan

On Apr 15, 11:45 pm, Sean Kinsey <okin...@gmail.com> wrote:
> I just wanted to inform you about the easyXDM library(http://
> easyxdm.net), a library that enables cross-domain RPC between two
> between two loaded HTML documents. The library uses a protocol almost
> identical to JSON-PRC, and will shortly be brought more in line with
> the spec.
>

> You can take a look athttp://easyxdm.net/wp/2010/03/17/remote-procedure-calls-rpc/

> to read more about using the easyXDM.Rpc class, or you could skip

> right to one of the demoshttp://easyxdm.net/current/example/methods.html.

>
> The underlying transport supports the use of several different stacks,
> FIM (Fragment Identifier Messaging), window.name and postMessage.
> All transports are reliable (even the FIM), supports queuing and
> fragmenting, and enforces sender-verification.
>
> One of the current demos, showing cross-domain XHR (http://
> consumer.easyxdm.net/example/xhr.html) displays the use of the generic
> XMLHttpRequest RPC interface, that enables cross-domain ajax, and one
> of the ideas I have is to extend this so that it can talk to a generic
> JSON-RPC server using HTTP.
> The end result would be to be able to expose a JSON-RPC-over-HTTP-
> enabled server with very little code.
> Does anyone have any suggestions for this, or wish to contribute? The
> code that would need extending, or that would be best used as a base

> is the current xhr.html document,http://github.com/oyvindkinsey/easyXDM/blob/master/src/xhr.html

[Sean Kinsey]

On Apr 17, 12:27 am, Ivan Zuzak <izu...@gmail.com> wrote:
> Looks cool, Sean!
>
> You should also check out pmrpc, a JS library that does basically the
> same thing - HTML5 inter-window and web workers remote procedure call
> library (uses JSON-RPC as message format).http://code.google.com/p/pmrpc/
>

Yes, I'm aware of that, and I'm afraid it's applications are rather
limited except where the availability of postMessage is guaranteed.
easyXDM even supports IE6 (and probably older browsers too).
Also, I think easyXDM's API is cleaner with the automatic stub
generation etc.

[Sean Kinsey]

On Apr 17, 12:27 am, Ivan Zuzak <izu...@gmail.com> wrote:

> Looks cool, Sean!
>
> You should also check out pmrpc, a JS library that does basically the
> same thing - HTML5 inter-window and web workers remote procedure call
> library (uses JSON-RPC as message format).http://code.google.com/p/pmrpc/

If you want pmrcp to really be considered for production use, then you
should probably do something about the quality of the code.
Eg.
http://code.google.com/p/pmrpc/source/browse/trunk/pmrpc.js:102
for (var paramName in params) {
if (typeof argIndexes[paramName] !== "undefined") {
callParameters[argIndexes[paramName]] = params[paramName];
} else {
throw "No such param!";
}
}

This is going to break in all documents where Object.prototype has
been augmented (read PrototypeJs).

There are also several variables that are declared multiple times
(inside conditional blocks), and also several undeclared variables
(that will be hoisted to the global scope).
http://code.google.com/p/pmrpc/source/browse/trunk/pmrpc.js:212
If any other scripts on the page were to depend on a global 'message'
variable, then you would break their code.

And what is 'Exception'?
http://code.google.com/p/pmrpc/source/browse/trunk/pmrpc.js:363
throw new Exception("number of retries must be 0 or higher");

ECMAScript-262
http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf
15.11.6 defines the available Error types, Exception is not one of
those.

But this is probably more a discussion for comp.lang.javascript :)

[Matt (MPCM)]

I am sure the project author would be interested in patches if you
want to send them over. : )

--
Matt (MPCM)

[Sean Kinsey]

On Apr 17, 11:43 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> I am sure the project author would be interested in patches if you
> want to send them over. : )

Why would I want to patch a 'competing' library, and a lesser one at
that ;)

[Ivan Zuzak]

Thanks for the code review, Sean :). You're definitely right about the
code quality not being production-level (and btw. supporting IE6 and
being proud of it is so last Friday). Although that was never the
purpose of the project, I don't think it would take a lot of effort to
make it production-level. It's more of a proof of concept to get
feedback from people on new tech e.g. inter-worker and inter-window
communication using the same mechanism.

Matt - thanks for babysitting us :D

Ivan

[Sean Kinsey]

On Apr 18, 9:23 am, Ivan Zuzak <izu...@gmail.com> wrote:
> Thanks for the code review, Sean :). You're definitely right about the
> code quality not being production-level (and btw. supporting IE6 and
> being proud of it is so last Friday).

Not when it is a critical feature for most 'real-life' applications;
and also, by IE6 I pretty much meant 'all browsers not supporting
postMessage'.

> Although that was never the
> purpose of the project, I don't think it would take a lot of effort to
> make it production-level. It's more of a proof of concept to get
> feedback from people on new tech e.g. inter-worker and inter-window
> communication using the same mechanism.

It was not my intention to criticize the project, you implemented the
RPC feature before me (although I didn't now about it until later),
and I have no doubt it works.

[Ferenc Kovacs]

On Sun, Apr 18, 2010 at 5:21 AM, Sean Kinsey <oki...@gmail.com> wrote:

On Apr 17, 11:43 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> I am sure the project author would be interested in patches if you
> want to send them over. : )

Why would I want to patch a 'competing' library, and a lesser one at
that ;)

Welcome in the open source world! :)

Tyrael

[Luis Montes]

Interesting stuff.

Any idea how it compares to dojo.rpc.RpcService / dojo.rpc.JsonpService ?

Luis

[Sean Kinsey]

On May 3, 10:57 pm, Luis Montes <monte...@gmail.com> wrote:
> Interesting stuf

>
> Any idea how it compares to dojo.rpc.RpcService / dojo.rpc.JsonpService ?

I haven't looked closely at it, but all as far as I'm aware of all of
dojo's rpc features depends on a server component.
easyXDM's strength is that it is strictly window <-> window, and so
facilitates communication between the two contexts (user <-> domainA
and user <-> domainB).
This means that you can actually maintain a *state* on both ends,
something that is pretty much impossible while using JSONP and other
server based methods.

Sean Kinsey

[Sean Kinsey]

Just to let you know - as of v2.3.0, easyXDM can now offer RPC with
<15ms transits with *no* server side dependencies for IE6+, Opera 9+,
Firefox 3+ Safari 4+ and Chrome 2+.
All you need is to include easyXDM in the two documents

See http://easyxdm.net/wp/2010/05/22/v2-3-0-is-out/ for more.