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