[
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: (was: 0.9.2)
0.9.3
> 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
> Labels: iwc, messaging
> Fix For: 0.9.3
>
> 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] 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
