[jira] Updated: (WOOKIE-133) Implement inter-widget messaging

["Scott Wilson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Wilson updated WOOKIE-133:
--------------------------------

    Fix Version/s: 0.8.2

Scheduling for 0.8.2

> Implement inter-widget messaging
> --------------------------------
>
>                 Key: WOOKIE-133
>                 URL: https://issues.apache.org/jira/browse/WOOKIE-133
>             Project: Wookie
>          Issue Type: New Feature
>          Components: Server, Wookie REST API
>            Reporter: Scott Wilson
>            Priority: Minor
>             Fix For: 0.8.2
>
>   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] http://groups.google.com/group/talk-about-widgets/web/use-cases-for-iwc
> [2] http://forge.morfeo-project.org/wiki/index.php/Gadget_development_guide

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.