[pmrpc] Inter-widget communication using pmrpc

[Pedro]

Hi everyone,

Ivan, I've been reading your blog post (http://izuzak.wordpress.com/
2009/10/10/inter-window-browser-communication-and-how-to-make-it-
better/): pmrpc looks awesome, and I'm looking foward to using it.

Still, I have a question:

I'm developing widgets for an iGoogle-like portal, and I'd like my
widgets to communicate with each other.

I've been unsuccessfully trying with the postmessage API, but as the
widgets and the portal are located on two differents servers, I
encounter a cross-domain related permission denial.

Indeed, I need widgetA to send a message to widgetB.
With postmessage, I need widgetB's window object reference, and that
piece of information is only avalaible inside the portal. The portal
is located on a different server, thus I get a "permission denied".

I can't access the portal source code, so I was wondering whether
pmrpc would help my widgets communicate with each other "directly" ?

Thanks!!



--
Subscription settings: http://groups.google.com/group/pmrpc/subscribe?hl=en

[Ivan Žužak]

Hi Pedro,

Thanks for the kind words on pmrpc, I hope it will be of use to you!

Regarding your problem -- yeah, that's one of the few basic "issues"
with communication - when you want to send a message, you have to know
who you're sending it to. In order to send a message using pmrpc,
you'd also have to obtain a reference to the destination widget.
Postmessage can do anything pmrpc can (since pmrpc is based on
postmessage), the benefit of using pmrpc is that it's a lot easier
(less boilerplate code).

Here's what you should be able to do to get the reference you need:
- most portals assign identifiers to the widgets in the following way
-- the portal HTML has <iframe> elements for each widget and each
<iframe> element has, other than the "src" attribute, a "name"
attribute. For example, iGoogle defines these names as
"remote_iframe_SOME_NUMBER" for each Google Gadgets
- lets say that the portal you are using has assigned the identifier
"child_1" to the sending widget and "child_2" to the receiving widget
- you should be able to do this (since it is not affected by same
origin policy) in the sending widget:
var receiverReference = window.parent.frames["child_2"];
- this will give you the reference to the receiving widget

- if you don't know under which name the widgets are identified in the
portal HTML, you can try sending a "ping" message to every iframe and
return the ping only from the receiving iframe. this way you'll know
which iframe is the one that should keep a reference of (again, code
for the sending widget):
for (var i=0; i<window.parent.frames.length; i++) {
var currentReference = window.parent.frames[i];
// send a ping to the currentReference and if you receive a response
- it's the iframe you seek
}

Does this make sense? If you need help - let me know and I'll whip up
a small example on a test page. Or let me know which portal you are
using so I can check what's going on exactly :).

In any case (both in pmrpc and postmessage), communication is direct,
however the process of obtaining the reference is not (since only the
portal page knows it).

Cheers,
Ivan

[Pedro]

Hi Ivan,

Thanks so much for your help, I really appreciate.

First, pinging every frames is working for me :)

That's great, but now I'd like to do something cleaner, ie. not
sending message to every widget in the portal.

Apparently, the portal is using some kind of random ID number, that
appears to be changing everytime you add/remove the widget:

<iframe frameborder="0" scrolling="no" src="http://myWidgetServer.org/
receivingWidget.php" id="1272440559045_iframe" style="height: 36px;"></
iframe>

Looks like the only way to be sure my sending widget is targeting the
receiving widget would be by using the src attribute - and
unfortunately, reading this attribute seems to be affected by the same
origin policy.

Do you have any hints on how to workaround this?

Thanks!

Pierre

[Ivan Žužak]

Hi Pierre,

Looking at the iframe element, I don't think there's a lot you can do
if you want to use postmessage or pmrpc:
- you are right, you cannot read **any** attribute of the <iframe> element.
- i don't see a "name" attribute set in the iframe element, so you
cant use the window.parent.frames["destination_iframe_name"] to get a
reference. the "id" attribute is irrelevant, and even if it were
relevant - it's generated randomly so that's a dead end.

Here are some possibilities (which you probably wont like):
- contact the portal owner and ask them to implement some form of
inter-widget communication that doesn't require explicit
identification (e.g. like the pubsub API iGoogle had before -
http://code.google.com/apis/gadgets/docs/pubsub.html).
- implement a browser extension that helps you, e.g. a browser
extension that reads all the iframe elements in the portal page and
sends the list to the sending widget and assigns "name" attributes to
each. the sending widget then has everything it needs to figure out
which iframe element it needs to send to.
- wait for me to implement the pinging approach in pmrpc so you don't
have to do it manually. this is actually the base of my next feature
in pmrpc that allows discovery of registered methods - pmrpc would
ping each iframe it can reach and in return it would get a list of all
methods registered on those iframes. then you'd be able to call the
method you want without knowing in advance which iframe implements it.
but, as I said, this would be implemented in pmrpc using the pinging
approach, it would just be hidden from developers using pmrpc (like
yourself). i'm not sure when i'll be finished with this feature,
though.

Also, maybe you can use some other type of mechanism to communicate
(other than postmessage):
- use a server-mediated inter-widget communication mechanism. Here's
how that would work: you'd implement a service somewhere on the Web
(e.g. on appengine), and both of your widgets would know it's URL. the
sending widget would send something to the URL (e.g. using POST), and
the receiving widget would poll the URL (e.g. using GET) to see if the
sender sent something. in other words, your widgets would communicate
using a commonly known server
- perhaps you could use cookies or webstorage
(http://dev.w3.org/html5/webstorage/) as a shared memory model, if all
the widgets are loaded from the same domain. here's how that would
work. since all the widgets are loaded from the same domain you can
access the same cookie/webstorage data from both widgets. thus, you
could write a message to a cookie/webstorage from the sending window,
and then read the data from the receiving window (e.g. by polling). I
didn't give this approach much thought, so I may have missed
something.

All in all - there's a lot of solutions, it just depends what your
project limitations are. The pinging approach is rather nice if you
ignore a few extra lines of code.

Hope this helps,
Ivan

[Pedro]

Hi Ivan,

Thanks a lot for your help, I had been looking for those answers on
the web for a few days now!

I think we'll stick with the basic pinging approach right now, but I
might be able to get the portal editor to include a name attribute for
the frames.
I'm also definitely waiting for your pinging approach implementation
in pmrpc!

Thanks again,

Pierre

On Apr 28, 12:12 pm, Ivan Žužak <izu...@gmail.com> wrote:
> Hi Pierre,
>
> Looking at the iframe element, I don't think there's a lot you can do
> if you want to use postmessage or pmrpc:
> - you are right, you cannot read **any** attribute of the <iframe> element.
> - i don't see a "name" attribute set in the iframe element, so you
> cant use the window.parent.frames["destination_iframe_name"] to get a
> reference. the "id" attribute is irrelevant, and even if it were
> relevant - it's generated randomly so that's a dead end.
>
> Here are some possibilities (which you probably wont like):
> - contact the portal owner and ask them to implement some form of
> inter-widget communication that doesn't require explicit

> identification (e.g. like the pubsub API iGoogle had before -http://code.google.com/apis/gadgets/docs/pubsub.html).

[Ivan Žužak]

No problem, Pierre. Let me know if I can be of more help.

And, while we're on the subject -- is there anything more you'd like
to see implemented? any other feature? and how would you like the
discovery feature to work? would you like to discover only widgets by
some criteria (iframe name, iframe location, iframe id) or also
discover methods registered in those widgets also by some criteria
(methods that accept certain types of parameters, methods with a
particular name, etc..)? If you have any kind of input, it'd be
helpful so I can design something that people would be happy to use.

Thanks!
Ivan

[Pedro]

Hi Ivan,

Hope you're doing well!

I'm actually a real newbie in this area, so right now I can't tell you
exactly what could be of use to me. But be sure that I'll give you
some feedback as soon as possible!

Cheers

On Apr 28, 4:17 pm, Ivan Žužak <izu...@gmail.com> wrote:
> No problem, Pierre. Let me know if I can be of more help.
>
> And, while we're on the subject -- is there anything more you'd like
> to see implemented? any other feature? and how would you like the
> discovery feature to work? would you like to discover only widgets by
> some criteria (iframe name, iframe location, iframe id) or also
> discover methods registered in those widgets also by some criteria
> (methods that accept certain types of parameters, methods with a
> particular name, etc..)? If you have any kind of input, it'd be
> helpful so I can design something that people would be happy to use.
>
> Thanks!
> Ivan
>