Pmrpc - inter-widget cross-domain RPC library based on HTML5 postMessage API

28 views
Skip to first unread message

Ivan Zuzak

unread,
Oct 3, 2009, 8:30:03 AM10/3/09
to Talk about Widgets
Hi all,

I've seen lots of discussion regarding inter-widget communication on
this group so I just wanted to mention pmrpc (http://code.google.com/p/
pmrpc). Pmrpc is a JavaScript library for cross-domain inter-window
RPC communication that uses the new HTML5 postMessage API for
transport. The library provides a simple API for exposing and calling
procedures from windows or iFrames on different domains, and also
provides several advanced features like callbacks, ACL-based access
control and automatic retries. The main reason for developing pmrpc
was the lack of easier to use and more advanced communication and
access-control mechanisms in the postMessage API which supports only
basic messaging.

Since widgets are mostly implemented as iframes within a container
window, pmrpc can be used for inter-widget communication. It's worth
noting that, since widgets communicate directly, using pmrpc doesn't
require any code changes on the container rather only in the widgets
themselves (i.e. loading the pmrpc library).

Check out the project homepage for more information - http://code.google.com/p/pmrpc/.
Feedback and discussions are appreciated. :)

Regards,
Ivan

Scott Wilson

unread,
Oct 3, 2009, 11:43:34 AM10/3/09
to Talk about Widgets
Hi Ivan, and welcome!

This sounds very useful - recently I've seen models for inter-widget
messaging from several groups, and it would be great to bring those
together here to what the different approaches bring, and where there
is commonality.

S
> Check out the project homepage for more information -http://code.google.com/p/pmrpc/.

Ivan Zuzak

unread,
Oct 4, 2009, 6:43:26 AM10/4/09
to Talk about Widgets
Hey Scott,

Definitely! A lot of groups and projects (OpenAjax, OpenSocial and
Shindig, W3C widgets) are poking at this problem on various levels,
from low-level communication primitives (postMessage, server-side
proxied communication, cookies, URL fragments) to high-level
abstractions (messaging, rpc, pub-sub, shared memory) and even new
browser architectures (MS Gazelle and Chromium). I'm actually in the
process of screening all previous work (both research and development)
on inter-window communication and hope to come back here to share the
"big picture" overview.

Is there anything else you can point me to? Keywords should be enough
so I can Google away :).

Thanks!
Ivan

On Oct 3, 5:43 pm, Scott Wilson <scott.bradley.wil...@gmail.com>
wrote:

Scott Wilson

unread,
Oct 4, 2009, 12:18:29 PM10/4/09
to talk-abou...@googlegroups.com
Hi Ivan,

I think you've managed to name most if not all of the approaches I've
come across - I guess I split these between browser-side (postMessage,
shared cookies, JS dependency injection, container-specific hooks and
APIs) and server-side ("classic" message queue services, pubsubhubbub,
shared states, comet, xmpp...)

As I mostly work on Apache Wookie, and with some mobile stuff (Bondi)
my main interest would be server-side - or at least capable of being
abstracted to a level where it doesn't matter whether the "source" and
"sync" widgets are in the same browser or on completely different
devices.

Tobias Nelkner I know has an approach that uses widget proximity to
trigger sharing; Stephane Sire and other colleagues working on
MyWiWall have a client-side solution, and Matthias Palmer had
something I think perhaps at the architecture level. There have also
been some proposals I've seen for declarative models which try to be
transport-agnostic (I'll have to dig around and find them).

Its great you've made a good start on making sense of all this!

S

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Talk about Widgets" group.
> To post to this group, send email to talk-abou...@googlegroups.com
> To unsubscribe from this group, send email to talk-about-widg...@googlegroups.com
> For more options, visit this group at http://groups.google.fr/group/talk-about-widgets?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

Tobias Nelkner

unread,
Oct 4, 2009, 1:02:37 PM10/4/09
to talk-abou...@googlegroups.com
Hi Ivan, hi all!

As Scott said, we are developing a server side solution for inter-
widget communication. This solution allows the communication between
applications (web and desktop widgets) in general and we are putting
much effort in working on APIs for Javascript, Java, Flex, PHP and
others. You can have a look at the proximity based example mentioned
by Scott under http://tinyurl.com/yc7kkkx , password is "Mature4ip", A
more general presentation of the approach (including screencasts) can
be found under http://tinyurl.com/ybo632y

Best wishes,
Tobias.

Ivan Zuzak

unread,
Oct 5, 2009, 9:27:56 AM10/5/09
to Talk about Widgets
Great pointers, Scott. Thanks! Also, I like your client-side vs server-
side way of partitioning of the approaches. I think a good start for
getting a grasp around the whole inter-widget communication ecosystem
is to determine exactly these kinds of dimensions (e.g. client vs
server side, simple messaging vs pubsub vs rpc vs shared state).

Can you explain a bit the need for inter-widget communication (IWC) in
Wookie? Was it implemented only for the state sharing feature of the
Google Wawe Gadgets or are there other W3C Widgets / Wave Gadgets /
REST API features that require IWC? Glancing through the docs led me
to the conclusion that state sharing is the only reason for IWC so
far.

Thanks,
Ivan

On Oct 4, 6:18 pm, Scott Wilson <scott.bradley.wil...@gmail.com>
>  smime.p7s
> 3KViewDownload

Ivan Zuzak

unread,
Oct 5, 2009, 9:32:37 AM10/5/09
to Talk about Widgets
Hi Tobias,

That's definitely one of the coolest IWC metaphors I've seen! Very
nice!
Can you point me to any documentation on how this communication works
(from a technology standpoint, not the end-user standpoint)?

Cheers,
Ivan

On Oct 4, 7:02 pm, Tobias Nelkner <to...@upb.de> wrote:
> Hi Ivan, hi all!
>
> As Scott said, we are developing a server side solution for inter-
> widget communication. This solution allows the communication between  
> applications (web and desktop widgets) in general and we are putting  
> much effort in working on APIs for Javascript, Java, Flex, PHP and  
> others. You can have a look at the proximity based example mentioned  
> by Scott underhttp://tinyurl.com/yc7kkkx, password is "Mature4ip", A  
> more general presentation of the approach (including screencasts) can  
> be found underhttp://tinyurl.com/ybo632y

Scott Wilson

unread,
Oct 5, 2009, 9:37:27 AM10/5/09
to talk-abou...@googlegroups.com
Hi Ivan,

In Wookie there is only shared state using the Google Wave Gadgets API
- and this is implemented as a Feature extension for W3C Widgets.

As several Wookie users have added their own IWC mechanism in various
forms I'm assuming there is a requirement here for other IWC
functionality.

S

Tobias Nelkner

unread,
Oct 5, 2009, 10:09:04 AM10/5/09
to talk-abou...@googlegroups.com
Hi Ivan,

the corresponding paper explaining the technology behind the "Widget Server"-idea can be found here: files.me.com/tobiasnelkner/f2tz3u
Bibtex (and also the paper, if you have an accout) can be found here: http://springerlink.com/content/wm2r08466j217835/?p=53d5231b4bcc4909a52e7c2c0a02fdae&pi=1

Cheers, 
Tobias.

Ivan Zuzak

unread,
Oct 5, 2009, 12:25:35 PM10/5/09
to Talk about Widgets
Scott - I love it when users hack into the system and try to do
exciting stuff on their own. It tells you exactly what they need and
what you should support in next versions. Definitely worth studying
which use-cases your users are trying to solve with their IWC
mechanisms.

Thanks for all the info - I hope we'll get a chance to combine and
share our knowledge of IWC approaches. I'd really like to assemble a
document with a short overview of the approaches we both mentioned.

Ivan

On Oct 5, 3:37 pm, Scott Wilson <scott.bradley.wil...@gmail.com>
>  smime.p7s
> 3KViewDownload

Ivan Zuzak

unread,
Oct 5, 2009, 12:27:35 PM10/5/09
to Talk about Widgets
Thanks Tobias! I'll have a look at it later this week.

Ivan

On Oct 5, 4:09 pm, Tobias Nelkner <to...@upb.de> wrote:
> Hi Ivan,
>
> the corresponding paper explaining the technology behind the "Widget  
> Server"-idea can be found here: files.me.com/tobiasnelkner/f2tz3u
> Bibtex (and also the paper, if you have an accout) can be found here:http://springerlink.com/content/wm2r08466j217835/?p=53d5231b4bcc4909a...

Stephane

unread,
Oct 5, 2009, 1:22:25 PM10/5/09
to talk-abou...@googlegroups.com
On Oct 4, 2009, at 6:18 PM, Scott Wilson wrote:
> Tobias Nelkner I know has an approach that uses widget proximity to
> trigger sharing; Stephane Sire and other colleagues working on
> MyWiWall have a client-side solution, and Matthias Palmer had
> something I think perhaps at the architecture level. There have also
> been some proposals I've seen for declarative models which try to be
> transport-agnostic (I'll have to dig around and find them).

Hello Ivan,

MyWiWall implementation is based on preliminary ideas that were
drafted in a paper presented at MUPPLE'08 and where we discussed a
widget state coupling scenario, which is a generalization of widget
state sharing [1]. This widget state coupling scenario was not
implemented, at that time the idea was to have a widget data model
exposed as XML from which it would have been possible to devise also a
widget set (or portal, or page, or universe, or watever) data model
and to declare with some bindings that some parts of the data models
of some widgets should be synchronized. This was quite inspired by
XForms data model and bindings... The last year has shown that a
simpler key/property value data model was easier to describe widgets
state and to share it among the same instances of a widget :) THen it
turned out also that Dn'D was the proper way to go to synchronize
states between instances of different widgets.

MyWiWall implementation [2] is what Scott would call a client-side
one, maybe a "JS dependency injection" if what he calls like that
corresponds to Javascript code injection into the iframe holding the
widget. Inconvenient of that approach is that there is no security at
all (any misbehaved widgets could fake an event to another one I guess).

On Oct 5, 2009, at 3:32 PM, Ivan Zuzak wrote:
> That's definitely one of the coolest IWC metaphors I've seen! Very
> nice!

Quite interesting, if I have understood the proximity principle, this
make me thinks of "DataTiles" in other HCI research [3]

Please keep us informed about your findings :)

Stéphane S.
---

[1] Sire, S., Vagner, A.: Increasing Widgets Interoperability at the
Portal Level. In: Proceedings of the First International Workshop on
Mashup Personal Learning Environments (MUPPLE- 2008), Maastricht, The
Netherlands, September 17, 2008. Available at:
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-388/sire.pdf

[2] A messaging API for inter-widgets communication, Stéphane Sire,
Micaël Paquier, Alain Vagner, Jérôme Bogaerts, Proceedings of the 18th
international conference on World wide web, Madrid, Spain, POSTER
SESSION: Thursday, April 23, 2009, pp. 1115-1116, ACM New York, NY,
US. Available at:
http://www2009.eprints.org/138/

[3] http://www.sonycsl.co.jp/person/rekimoto/papers/chi01.pdf
and a video http://www.youtube.com/watch?v=cmD8EKWxD4M


Ivan Zuzak

unread,
Oct 5, 2009, 7:24:55 PM10/5/09
to Talk about Widgets
Hi Stephanie,

Thanks for the feedback! I've actually come across your WWW2009 poster
before, the MUPPLE'08 one I haven't seen and will definitely check it
out. The poster was very interesting, shame it's so short - I'd love
to read up a bit more on your ideas and thoughts for IWC (e.g.
different approaches, use-cases and usability insights). The Sony
DataTiles paper seems very interesting also, thanks for the reference.

So, if I understood you correctly - the state sharing model was not
implemented in any way (neither on a widget set level, nor on a widget
property level) and was replaced with the event based approach
described in the WWW2009 poster?

Ivan
> Netherlands, September 17, 2008. Available at:http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-388...

Stephane

unread,
Oct 6, 2009, 5:40:04 AM10/6/09
to talk-abou...@googlegroups.com
Hello,

On Oct 6, 2009, at 1:24 AM, Ivan Zuzak wrote:
> So, if I understood you correctly - the state sharing model was not
> implemented in any way (neither on a widget set level, nor on a widget
> property level) and was replaced with the event based approach
> described in the WWW2009 poster?

Yes that's it, two layers: event messaging (kind of pub-sub) + Dn'D on
top of it,

The code is quite simple as it is client-side, you can have a look to
the following source files into js/portal folder if you checkout
mywiwall (*) EventDispatcher.js, WidgetDragStub.js, DragManager.js

Basically this could be ported easily on other implementations,
however we had a discussion that maybe this is not required since Dn'D
implementation in HTML 5, with the pending question wether or not it
should be kept at the HTML level, or put in a widget API...

I argued in favor of the second because that would allow the widget
container to offer enhanced feedbacks. Also if there is a declarative
model of inter-widget comm., for instance in the configuration file,
this would opens up more user programming capabilites such as
explicitely or not connecting widgets together... But having a
declarative model of inter-widget comm. raises the issue of event
typing. For instance how a widget that accept a "location" can also
accept a "place" or a "landmark". This is required for scalability.
One solution is standardizatoin (I think Scott proposed a Dn'D based
on microformats data types), another one is semantic Web and
inference, but I am afraid this requires to define ontologies for
inter-widget comm (kind of RDF/RDFS description of widgets input/
output vocabularies :~).

On Oct 4, 2009, at 6:18 PM, Scott Wilson wrote:

> I guess I split these between browser-side (postMessage, shared
> cookies, JS dependency injection, container-specific hooks and APIs)
> and server-side ("classic" message queue services, pubsubhubbub,
> shared states, comet, xmpp...)

I would suggest to divide the server side category in two categories:

- inter-servers server side (or federated server side or any better
name)
- intra-server server side

The first category would allow event messaging between different
servers. It accounts for new emerging patterns such as WebHooks (from
which pubsubhubbub is a kind of implementation) which as far as I
understand require a target server to forward calls to in a more
economical way than permanent polling such as with XMPP-BOSH. See http://www.slideshare.net/progrium/web-hooks-google-tech-talk

However as long as the Web browser does not embed a server (such as
Opera Unite), the inter-servers inter-widgets comm. will also require
one of the other implementations to reach the widgets...

Stéphane S.
---

(*) http://code.google.com/p/mywiwall/

Ivan Zuzak

unread,
Oct 7, 2009, 10:38:15 AM10/7/09
to Talk about Widgets
On Oct 6, 11:40 am, Stephane <sts...@gmail.com> wrote:
> The code is quite simple as it is client-side, you can have a look to
> the following source files into js/portal folder if you checkout
> mywiwall (*) EventDispatcher.js, WidgetDragStub.js, DragManager.js

I'm a bit lost in the code. Considering only the EventDispatcher code
which I guess handles the distribution of created events - how do you
handle passing data between widgets loaded from different domains? Or
are all widgets created on the same domain?

> Basically this could be ported easily on other implementations,
> however we had a discussion that maybe this is not required since Dn'D
> implementation in HTML 5, with the pending question wether or not it
> should be kept at the HTML level, or put in a widget API...
>
> I argued in favor of the second because that would allow the widget
> container to offer enhanced feedbacks. Also if there is a declarative
> model of inter-widget comm., for instance in the configuration file,
> this would opens up more user programming capabilites such as
> explicitely or not connecting widgets together... But having a
> declarative model of inter-widget comm. raises the issue of event
> typing. For instance how a widget that accept a "location" can also
> accept a "place" or a "landmark". This is required for scalability.
> One solution is standardizatoin (I think Scott proposed a Dn'D based
> on microformats data types), another one is semantic Web and
> inference, but I am afraid this requires to define ontologies for
> inter-widget comm (kind of RDF/RDFS description of widgets input/
> output vocabularies :~).

I think you're spot on with formulating the problem. Defining the
format of the data that is passed around must be in some way known and
agreed upon by parties which want to exchange this data. Back in 2007
when I worked at Google (had an internship there), a colleague of mine
and myself worked on the design and implementation of the original
Google Gadgets pub-sub mechanism for exchanging data between Gadgets.
There were a couple of teams inside Google waiting to use this feature
once we were done and the interesting part was that they *in advance*
defined the exact format of all events they were going to pass around.
So for passing around locations the agreed upon it was going to be a
"lat, long" pair. And anyone who wanted to push data to a Maps Gadget
needed to structure the data that way and no other way worked.

The second problem is defining the semantics of the data. For example,
you could have several channels (eventTypes) on which Gadgets are
passing around the same data type (e.g. location) but which had
different meaning (e.g. one channel is used for current location, the
other for destination, and a third for points of interest). How would
the end-user connect these in the right way was a big problem.

>
> On Oct 4, 2009, at 6:18 PM, Scott Wilson wrote:
>
> > I guess I split these between browser-side (postMessage, shared
> > cookies, JS dependency injection, container-specific hooks and APIs)
> > and server-side ("classic" message queue services, pubsubhubbub,
> > shared states, comet, xmpp...)
>
> I would suggest to divide the server side category in two categories:
>
> - inter-servers server side (or federated server side or any better
> name)
> - intra-server server side
>
> The first category would allow event messaging between different
> servers. It accounts for new emerging patterns such as WebHooks (from
> which pubsubhubbub is a kind of implementation) which as far as I
> understand require a target server to forward calls to in a more
> economical way than permanent polling such as with XMPP-BOSH. Seehttp://www.slideshare.net/progrium/web-hooks-google-tech-talk
>
> However as long as the Web browser does not embed a server (such as
> Opera Unite), the inter-servers inter-widgets comm. will also require
> one of the other implementations to reach the widgets...

Yeah, that makes sense - federated vs. centralized approach. Within
those categories you still have different programming models such as
RPC, pub-sub, shared memory, and different data exchange models - pull
or push. In any case, there are lots of dimensions to consider and
identifying all the dimensions is, I believe, the first step in
sorting all the approaches in a consistent way.

Ivan

Stephane

unread,
Oct 27, 2009, 11:39:01 AM10/27/09
to talk-abou...@googlegroups.com
Hi Ivan,

I am sorry I didn't answer earlier, but at least I can say a few words
now. As far as I know, widgets in mywiwall are served from the samed
domain (mywiwall server) and they use specific "widget.httpGet" method
for XHR request, which is proxified by the mywiwall server. Anyway I
think that such proxified method will be obsolete in the future, since
Firefox and Webkit already implement cross-site XMLHTTPRequest (*)
[but how to configure clients and servers to exploit that features
with a widget engine in the middle or not is another story]

But to come back to inter-widget communication in mywiwall, as I
understand, the widget container is the main window into which there
is a single instance of an EventDispatcher object. This event
dispatcher simply matains a list of event handlers registered by the
widgets with the

Widget.prototype.addWidgetEventListener = function(eventType,
eventHandler, acceptedSource)
{
this.eventDispatcher.addWidgetEventListener(this.id, eventType,
eventHandler, acceptedSource);
}

function (in Widget.js)

Then when another widget fires an event with the following function
(in Widget.js)

Widget.prototype.fireWidgetEvent = function(target, eventType, data)
{
this.eventDispatcher.fireWidgetEvent(this.id, eventType, data, target);
}

The matching handlers are called from the event dispatcher (in
EventDispatcher.js) :

handler({eventType: eventType, eventData: eventData});

So the trick is that:

- the main window contains one "eventDispatcher" instance
- the widget object which is injected inside each iframe sub-window
that contains each widget gets a reference to that object, in Widget.js
this.eventDispatcher = eventDispatcher;

And here is the widget instance injection right after widget creation:

var doc = iframe.contentWindow || iframe.contentDocument;
...
doc.widget = new Widget(options,
eventDispatcher,
dragManager);

And this seems to work, without any security violation, at least until
now (but don't ask me what is the value for the "this" object in the
callback :). That's all I see at the moment, does it give you an anser ?

Stéphane
---

(*) http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html
and
https://developer.mozilla.org/en/HTTP_access_control

Ivan Zuzak

unread,
Oct 31, 2009, 6:16:53 PM10/31/09
to Talk about Widgets
Hi Stephane,

Yes, that makes perfect sense, thanks! The fact that both all the
widgets and the container are loaded from the same domain greatly
simplifies the design of the system, which is pretty neat.

As for the cross-domain XHR requests - I also hope that the Access
Control headers will make proxies obsolete, but we might have to wait
some time for that to happen since change happens really slowly on the
Internet and this change requires a modification in all HTTP servers
out there :).

Best,
Ivan
> (*)http://developer.apple.com/safari/library/documentation/AppleApplicat...
> andhttps://developer.mozilla.org/en/HTTP_access_control
Reply all
Reply to author
Forward
0 new messages