incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Wilson (JIRA)" <>
Subject [jira] [Updated] (WOOKIE-133) Implement inter-widget messaging
Date Mon, 22 Aug 2011 12:31:29 GMT


Scott Wilson updated WOOKIE-133:

    Fix Version/s:     (was: 0.9.1)

I think is too big a feature add to do for 0.9.1 - deferring it to 0.9.2.

> Implement inter-widget messaging
> --------------------------------
>                 Key: WOOKIE-133
>                 URL:
>             Project: Wookie
>          Issue Type: New Feature
>          Components: Server, Wookie REST API
>            Reporter: Scott Wilson
>            Priority: Minor
>              Labels: iwc, messaging
>             Fix For: 0.9.2
>         Attachments: coupling-widgets-patch.txt, shareddata-test-ltfll.wgt, shareddata-test-ltfll2.wgt,
shareddata-test.wgt, shareddata-test2.wgt
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> One of the more persistent new feature requests we've had for Wookie has been to extend
the mechanisms for inter-widget communication (IWC). As it currently stands, Wookie supports
two mechanisms for IWC:
> 1. Wave Shared States
> Wookie enables "sibling" widgets to share their state. This is exposed to widgets using
the Google Wave Gadget API, which enables widgets to submit state update deltas, and to register
a callback to notify them when their state has been updated by another widget instance. We
define siblings using the algorithm in org.apache.wookie.util.SiblingPageNormalizer; essentially
this is that the widget instance must be for the same widget, with the same shared data key,
and the same API key.
> 2. HTML5 Drag and Drop
> While not actually part of Wookie itself, Widgets can be developed using HTML5 drag and
drop capability, enabling user-directed IWC.
> Some use-cases for IWC have been collected on the Talk About Widgets mailing list.
> The most common use-cases for extending IWC proposed for Wookie I've seen involve "Dashboard"-style
messaging. In this model, widgets appearing in the same space for the user get to share events.
For example, all the widgets in a single user's dashboard can send data to each other. This
might follow a single shared state model, but is more likely to follow a "channel" metaphor,
with named "channels" or "queues" between widgets. There are several ways this could be implemented,
for example:
> A. User-specified channels
> In this model, the user specifies exactly which messages are sent between widgets. For
example, the EzWeb project defines a "wiring" interface with "slots" and "events" connected
with user-created "channels". For example, the user create a channel from a widget with a
"weather" event to a widget with a "weather" slot. 
> B. Widget-specified channels
> In this model, widgets are automatically able to receive any events on any channel that
they choose to listen to. Users do not need to create channels to enable IWC.
> These two mechanisms are not necessarily exclusive, and could be supported within the
same Feature extension. For example, the JavaScript API may look like this:
> iwc.sendEvent(String event_name, Object event_value)
> iwc.registerCallback(String slot_name, Function callback)
> I would prefer having this IWC extension use its own functions in its own object rather
than overload the Wave and Widget objects, to avoid any possible confusion.
> In case "A", callbacks are only triggered where there are explicit channels linking the
sending event and the receiving slot; in case "B", events are propagated to all registered
callbacks that the event_name matches.
> For example, in pseudocode, the implementation could look something like:
> sendEvent(event_name, value, idkey){
> 		instance = find widget instance (idkey)
> 		if use_channels:
> 			event = find event(instance.getWidget, event_name)
> 			find channels (eventinstance = instance & event = event_name)
> 			for channel in channels:
> 				slot = channel.slot
> 				send notification to slot (target, slot, value)
> 				Notifier.notifySingleInstance(target,"iwc.__callback({slot},{value})")
> 		else:	
> 			Notifier.notifySiblingsByUser(instance,"iwc.__callback({event_name},{value})")
> }
> Note that in case "A", the widget author just registers callbacks for its slots without
having to be concerned with what the sending widget calls them, so if a user can wire a "weather"
event to a "temperature" slot, the sending widget calls:
> sendEvent("weather","30C");
> and the receiver can call:
> registerCallback("temperature",my_function); 
> ... and the channel wires things up despite the names not matching. In case B, the receiving
widget would have to know the name of the event, and register a callback.
> In case A, widgets need to declare their "events" and "slots" as extensions in config.xml
so they can be wired up in channels by a user, and there needs to be some sort of UI where
users get to do some wiring. Wookie could expose an API for creating/removing/editing channels
that could be implemented by containers rather than provide this UI itself.
> (Interestingly, case A would in theory support situations where widgets send notifications
to widgets in different containers; though I think this would only really work if we went
did the OpenID implementation so could have some assurance that the source and target widget
instances belonged to the same user).
> [1]
> [2]

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message