You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by "Scott Wilson (JIRA)" <ji...@apache.org> on 2010/04/06 20:55:33 UTC
[jira] Created: (WOOKIE-133) Implement inter-widget messaging
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
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.
[jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by "Ross Gardler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922286#action_12922286 ]
Ross Gardler commented on WOOKIE-133:
-------------------------------------
Bernhard indicates on the dev list that his project has a template for IWC widgets. The code is currently at https://ltfll.svn.sourceforge.net/svnroot/ltfll/Wp2/widgets/_template/src/
To use the coupling-widgets-patch.txt you need to see https://ltfll.svn.sourceforge.net/svnroot/ltfll/Wp2/widgets/_template/src/README
(The following is untested at the time of writing)
Specifically (for JSON IWC):
config.xml
--------------
<feature name="http://www.getwookie.org/usefeature/polling" required="true"/>
index.html
--------------
<script type="text/javascript" src="lib/iwc.js"></script>
call IWCinit('JSON', true) on widgets onLoad event
implement:
function IWCVARIABLE_NAME_1(data) {
//do something with the newly received data
} where VARIABLE_NAME_1 is the name of the variable being monitored
> 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.9.1
>
> Attachments: coupling-widgets-patch.txt
>
> 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.
[jira] Issue Comment Edited: (WOOKIE-133) Implement inter-widget
messaging
Posted by "Bernhard Hoisl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922521#action_12922521 ]
Bernhard Hoisl edited comment on WOOKIE-133 at 10/19/10 7:20 AM:
-----------------------------------------------------------------
Hi again,
I have re-created the shared data testing widgets using my LTfLL widget-template and storing variables in JSON data format (see files shareddata-test-ltfll.wgt and shareddata-test-ltfll2.wgt) .
Cheers,
Bernhard
was (Author: hoisl):
Hi again,
I have re-created the shared data testing widgets using my LTfLL widget-template and storing variables in JSON data format (see files shareddata-test-ltfll.wgt and shareddata-test-ltfll.wgt) .
Cheers,
Bernhard
> 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.9.1
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WOOKIE-133) Implement inter-widget messaging
Posted by "Bernhard Hoisl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernhard Hoisl updated WOOKIE-133:
----------------------------------
Attachment: shareddata-test2.wgt
shareddata-test.wgt
Hi,
we have to differentiate a little bit. Ross, your former posts indicate that you *have* to use the template I provide at SourceForge in order to use the patch and therefore IWC functionality. This is not the case. The widget template only provides more sophisticated routines for handling IWC data, but it doesn't matter if you use my patch. Without my patch the template and its IWC functions still work, but you are not able to, for example, send data from one widget to a complete different one (e.g. in one user space).
OK, so for testing my patch you can simply use the routines Wookie provides out-of-the-box, as setSharedDataForKey() etc. I do use them in my template anyways, but have built some routines around them to ease my (our) life with handling shared data.
Therefore, when it some to testing: I have created two instances for simple testing of Wookie's shared data behaviour. I have build them using Wookie's ant routines including the new style skeleton.
With the widget you can just set new shared data by using an input text field. Set data is then displayed in the footer of the widget.
If you deploy them on a Wookie instance and have them running side-by-side (I am doing this by using Elgg) you can test the behaviour of setting shared data and retrieving updates. I recommend using four widgets side-by-side, twice the shareddata-test and twice the shareddata-test2.
Scenario 1: Unmodified IWC
If you set a new variable using shareddata-test, the second instance gets updated, as well, but not the two instances of shareddata-test2. The same behavior applies for both widget instances of shareddata-test2.
Scenario 2: Patched IWC (with default configuration, that is all widgets of one user get notified)
If you now set a variable using shareddata-test2, not only the second instance of shareddata-test2 gets updated, but also both instances of shareddata-test (vice versa). You can check which widget has set the data as I store the widget-ID along with the message you typed in.
Hope anybody can test the patch.
Regarding testing the template: I will try to build the same widgets as I provide here only by using the LTfLL template with, e.g. JSON shared data format.
-Bernhard
> 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.9.1
>
> Attachments: coupling-widgets-patch.txt, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by "Ross Gardler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922063#action_12922063 ]
Ross Gardler commented on WOOKIE-133:
-------------------------------------
Thank you so much for this patch Bernhard. One of us will review it ASAP.
> 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.9.1
>
> Attachments: coupling-widgets-patch.txt
>
> 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.
[jira] Updated: (WOOKIE-133) Implement inter-widget messaging
Posted by "Bernhard Hoisl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernhard Hoisl updated WOOKIE-133:
----------------------------------
Attachment: shareddata-test-ltfll2.wgt
shareddata-test-ltfll.wgt
Hi again,
I have re-created the shared data testing widgets using my LTfLL widget-template and storing variables in JSON data format (see files shareddata-test-ltfll.wgt and shareddata-test-ltfll.wgt) .
Cheers,
Bernhard
> 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.9.1
>
> 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.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by Bernhard Hoisl <be...@wu.ac.at>.
> OK I got it - so you propagate the shared data update to all widgets (of any type) that have the same shareddatakey and API key. That then cascades the notifications to their siblings.
Yes, this is the UC we are dealing with.
> It certainly has the benefit of simplicity, and looks like it works nicely for the UC. I do wonder though if this kind of UC can also be handled purely client-side using things like PostMessage and open-app[1]? I think Mattias Palmer was doing something with this for a widget portal project he was working on.
I think: yes, if all browser would support HTML5. An advantage now is
storage of the variables in the Wookie database. So information don't
get lost.
> There is also a reset() method that hasn't been implemented yet that clears all the shared state [2].
Ah yes, this would be nice!
> Great bit of refactoring there! I'll leave the comment in Notifier just in case we need it later, but your new solution looks much simpler - as you say the trick is to see if we can generalize it a bit and maybe add some other levels of control over the "channels" that are enabled by the user. Maybe for now we might use your patch but have it deactivated by default and have a switch in widgetserver.properties to enable it?
A switch for enabling it would be perfect!! Generalization could then be
done in-line with other IWC ideas, as you said.
-Bernhard
>
>>
>>
>>
>> On 07/10/10 11:44, Scott Wilson (JIRA) wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918864#action_12918864 ]
>>>
>>> Scott Wilson commented on WOOKIE-133:
>>> -------------------------------------
>>>
>>> Thanks, Ivan. Your table is my number one source of info on IWC!
>>>
>>>
>>>
>>>> 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
>>>> 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
>>>
>> <WidgetAPIImpl.java>
>
>
Re: [jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by Scott Wilson <sc...@gmail.com>.
On 8 Oct 2010, at 13:36, Bernhard Hoisl wrote:
>
> Very interesting comment and I would be the first to use a "channel" metaphor for routing messages to specific widgets. As some of you know we here at WU Vienna have worked some time ago on IWC for exactly this kind of purpose - namely to notify all widgets in a certain user space (we are using widgets in Elgg, therefore all widgets displayed in a dashboard of one user).
>
> As I gave the code a review just recently I did come up with a new solution wiring together widget instances sharing the same sharedDataKey and apiKey (excerpt of new code attached). We are using the code right now because it fulfills exactly our purpose, but if someone comes up with a generic solution I would be even happier.
>
> It is by now not entirely clear where to best put the code to: Notifier, WidgetAPIImpl or another class because all have advantages and disadvantages. The Notifier class (as proposed by Scott Wilson) would be a good fit, but code there should only notify widgets and not set data. I not only want to notify other widgets of events happening in one user space but also share the data with all of them, therefore I have to call PropertiesController.updateSharedDataEntry() as well to set the data for all instances.
>
> Therefore, I adjusted WidgetAPIImpl.setSharedDataForKey() and appendSharedDataForKey() accordingly to notify and set data for all widgets having the same sharedDatakey and apiKey as the widget instance data was initially set.
>
OK I got it - so you propagate the shared data update to all widgets (of any type) that have the same shareddatakey and API key. That then cascades the notifications to their siblings.
> It is somehow a hack, because if you want to make it generic you should give config variables for the sibling attributes, for example in the local.widgetserver.properties. But anyway I liked the idea of configuring message buses using these sibling attributes because multiple combinations could be useful.
It certainly has the benefit of simplicity, and looks like it works nicely for the UC. I do wonder though if this kind of UC can also be handled purely client-side using things like PostMessage and open-app[1]? I think Mattias Palmer was doing something with this for a widget portal project he was working on.
> I just wanted to share my code with you guys and maybe hear some comments.
Thanks! Always appreciated!
>
> BTW: Quite hard to find out was how you actually one can delete shared data. By setting a variable to null, but there is no actual method for doing this (only a hack in PropertiesController.updateSharedDataEntry() exists, which is a not very consistent logic). Maybe a method deleteSharedDataEntry() would be useful?
There is also a reset() method that hasn't been implemented yet that clears all the shared state [2].
> @Scott: I completely re-designed the former approach of notifying widgets, which now does not rely on attributes set in the ScriptSession anymore. Therefore, your code comment at the end of Notifier.java is somehow obsolete and if needed could be dramatically simplified (or completely deleted). Moreover, I tried to change as less as possible at the existing code of Wookie, therefore no changes in wookie-wrapper.js or dwr.xml or a new DWRSessionRemote.js is needed for that (as was in the former version).
Great bit of refactoring there! I'll leave the comment in Notifier just in case we need it later, but your new solution looks much simpler - as you say the trick is to see if we can generalize it a bit and maybe add some other levels of control over the "channels" that are enabled by the user. Maybe for now we might use your patch but have it deactivated by default and have a switch in widgetserver.properties to enable it?
>
>
> Best,
> Bernhard
[1] http://code.google.com/p/open-app/
[2] https://issues.apache.org/jira/browse/WOOKIE-110
>
>
>
> On 07/10/10 11:44, Scott Wilson (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918864#action_12918864 ]
>>
>> Scott Wilson commented on WOOKIE-133:
>> -------------------------------------
>>
>> Thanks, Ivan. Your table is my number one source of info on IWC!
>>
>>
>>
>>> 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
>>> 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
>>
> <WidgetAPIImpl.java>
Re: [jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by Bernhard Hoisl <be...@wu.ac.at>.
Very interesting comment and I would be the first to use a "channel"
metaphor for routing messages to specific widgets. As some of you know
we here at WU Vienna have worked some time ago on IWC for exactly this
kind of purpose - namely to notify all widgets in a certain user space
(we are using widgets in Elgg, therefore all widgets displayed in a
dashboard of one user).
As I gave the code a review just recently I did come up with a new
solution wiring together widget instances sharing the same sharedDataKey
and apiKey (excerpt of new code attached). We are using the code right
now because it fulfills exactly our purpose, but if someone comes up
with a generic solution I would be even happier.
It is by now not entirely clear where to best put the code to: Notifier,
WidgetAPIImpl or another class because all have advantages and
disadvantages. The Notifier class (as proposed by Scott Wilson) would be
a good fit, but code there should only notify widgets and not set data.
I not only want to notify other widgets of events happening in one user
space but also share the data with all of them, therefore I have to call
PropertiesController.updateSharedDataEntry() as well to set the data for
all instances.
Therefore, I adjusted WidgetAPIImpl.setSharedDataForKey() and
appendSharedDataForKey() accordingly to notify and set data for all
widgets having the same sharedDatakey and apiKey as the widget instance
data was initially set.
It is somehow a hack, because if you want to make it generic you should
give config variables for the sibling attributes, for example in the
local.widgetserver.properties. But anyway I liked the idea of
configuring message buses using these sibling attributes because
multiple combinations could be useful.
I just wanted to share my code with you guys and maybe hear some comments.
BTW: Quite hard to find out was how you actually one can delete shared
data. By setting a variable to null, but there is no actual method for
doing this (only a hack in PropertiesController.updateSharedDataEntry()
exists, which is a not very consistent logic). Maybe a method
deleteSharedDataEntry() would be useful?
@Scott: I completely re-designed the former approach of notifying
widgets, which now does not rely on attributes set in the ScriptSession
anymore. Therefore, your code comment at the end of Notifier.java is
somehow obsolete and if needed could be dramatically simplified (or
completely deleted). Moreover, I tried to change as less as possible at
the existing code of Wookie, therefore no changes in wookie-wrapper.js
or dwr.xml or a new DWRSessionRemote.js is needed for that (as was in
the former version).
Best,
Bernhard
On 07/10/10 11:44, Scott Wilson (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918864#action_12918864 ]
>
> Scott Wilson commented on WOOKIE-133:
> -------------------------------------
>
> Thanks, Ivan. Your table is my number one source of info on IWC!
>
>
>
>> 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
>> 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
>
[jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by "Scott Wilson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918864#action_12918864 ]
Scott Wilson commented on WOOKIE-133:
-------------------------------------
Thanks, Ivan. Your table is my number one source of info on IWC!
> 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
> 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.
[jira] Commented: (WOOKIE-133) Implement inter-widget messaging
Posted by "Ivan Zuzak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866550#action_12866550 ]
Ivan Zuzak commented on WOOKIE-133:
-----------------------------------
I've started compiling a list of cross-context communication systems for web browsers. This might help get you started with implementing IWC for wookie -- lots of references and systematization of approaches taken by others.
More info on the Talk about Widgets group: http://groups.google.com/group/talk-about-widgets/browse_thread/thread/0309d7868dcc0e51#
Cheers,
Ivan
> 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
> 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.
[jira] Updated: (WOOKIE-133) Implement inter-widget messaging
Posted by "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.
[jira] Updated: (WOOKIE-133) Implement inter-widget messaging
Posted by "Bernhard Hoisl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernhard Hoisl updated WOOKIE-133:
----------------------------------
Attachment: coupling-widgets-patch.txt
I have created a patch out of my developments for IWC to be able to specify coupling widgets in widgetserver.properties. There, you can enter any combination of attributes which are used to find coupling widget instances. If widget.iwc.coupling is commented out (default), nothing changes to the notify behavior of Wookie.
Actually, it would be possible to simplify the code, because as default we could state
widget.iwc.coupling = apiKey, sharedDataKey, idKey
which is the exact same behavior as Wookie acts now. But as to do not interfere with existing developments I made an if-else switch, as that my code comes only in place if a user explicitly uncomments widget.iwc.coupling.
Inter-widget communication as used by myself was not intended at the time designing shared data update behavior for Wookie. Therefore, it does not fit as nicely as it could, but for the time being I think it is sufficient. When more sophisticated approaches emerge a re-factoring of setting shared data, receiving updates and notifications should be envisioned.
> 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.9.1
>
> Attachments: coupling-widgets-patch.txt
>
> 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.