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 2011/02/11 17:27:57 UTC
[jira] Created: (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Flatpack: Allow exporting of Widgets including instance information.
--------------------------------------------------------------------
Key: WOOKIE-182
URL: https://issues.apache.org/jira/browse/WOOKIE-182
Project: Wookie
Issue Type: New Feature
Components: Parser, Server
Reporter: Scott Wilson
The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
Also the user experience and documentation needs some thought.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Scott Wilson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Wilson updated WOOKIE-182:
--------------------------------
Fix Version/s: (was: 0.10.0)
0.10.1
Kicking this one further down the road as its not a high priority
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.10.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] Updated: (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Scott Wilson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Wilson updated WOOKIE-182:
--------------------------------
Fix Version/s: 0.9.1
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Fix For: 0.9.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Scott Wilson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129609#comment-13129609 ]
Scott Wilson commented on WOOKIE-182:
-------------------------------------
Its intended to be detached, so start files pointing into Wookie is definitely a bug.
I'd suggest rejecting it and punting to 0.9.2 so its not a blocker, and add sorting out the start files as another sub-task.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Scott Wilson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139752#comment-13139752 ]
Scott Wilson commented on WOOKIE-182:
-------------------------------------
Hmm, I just tried this, and for WookieWiki I get:
<icon src="icon.png" />
<content src="index.html" type="text/html" encoding="UTF-8" />
<feature name="http://wave.google.com" required="true" />
<preference readonly="true" name="sharedDataKey" value="1502709740" />
The code that replaces the "unpacked" paths with the original ones is in org.apache.wookie.w3c.util.WidgetOutputter.replacePaths(). I'm not sure why it didn't do this when Paul was testing.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.2
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Paul Sharples (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143125#comment-13143125 ]
Paul Sharples commented on WOOKIE-182:
--------------------------------------
I fixed the issue where the paths under windows still pointed to wookie instances in config.xml. Now the paths revert back to the original paths before the widget was imported (as it did on the mac).
There are still issues with what is actually being flatpacked. The wookie-wiki doesn't flatpack the wave feature for example.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.2
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Paul Sharples (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140050#comment-13140050 ]
Paul Sharples commented on WOOKIE-182:
--------------------------------------
I still have the same issues with this, even after a clean build & removing old subproject jars. It's possible it might be a windows paths specific issue, which I will investigate further.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.2
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Updated] (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Paul Sharples (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Sharples updated WOOKIE-182:
---------------------------------
Fix Version/s: (was: 0.12.0)
0.13.0
Moving to next release
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.13.0
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] Commented: (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Scott Wilson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002986#comment-13002986 ]
Scott Wilson commented on WOOKIE-182:
-------------------------------------
OK,WAC 2.0 now supports the W3C Widget Interface, so no need to create an API shim.
So I think the only things left now are how to include references to Wookie-injected scripts and the instance id key. These would need to use absolute instead of relative URLs.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Fix For: 0.9.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Scott Wilson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129612#comment-13129612 ]
Scott Wilson commented on WOOKIE-182:
-------------------------------------
I'll also add a caveat to its use in NEW_AND_NOTEWORTHY. There is already a note in the API docs.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Issue Comment Edited] (WOOKIE-182) Flatpack: Allow
exporting of Widgets including instance information.
Posted by "Paul Sharples (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129616#comment-13129616 ]
Paul Sharples edited comment on WOOKIE-182 at 10/18/11 9:39 AM:
----------------------------------------------------------------
Moving to 0.9.2 - this is not a blocker, but there are a few bugs that need to be resolved.
Just for pointers when we come to review this again...
(1) Any wookie features are injected into the the new flatpack instance directly and removed from its <feature> element found in the config.xml (the new JS scripts are then included in the new .wgt package)
"Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context. "
(2) A preference element (the sharededatakey) is added to the config.xml
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
(3) A flatpack instance is then *detached from wookie* altogether and designed to be imported elsewhere.
Is there anything else a flatpack must do?
Results of testing....
freeder
=======
seems to inject the scripts as expected - but the start path refers to a wookie path.
wookiewiki
===========
<icon src="/widgets/www.getwookie.org/widgets/wiki/icon.png" />
<content src="/widgets/www.getwookie.org/widgets/wiki/index.html" type="text/html" encoding="UTF-8" />
<feature name="http://wave.google.com" required="true" />
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
The icon path & start page path are incorrect - the icon and start page are in the root of the new flatpack .wgt file. Also the wave feature has not been replaced with an actual JS implementation and is still present in the config.xml
Simplechat
========
Same issues as woookiwiki
was (Author: psharples):
Moving to 0.9.2 - this is not a bloker, but there are a few bugs that need to be resolved.
Just for pointer when we come to review this again...
(1) Any wookie features are injected into the the new flatpack instance directly and removed from its <feature> element found in the config.xml (the new JS scripts are then included in the new .wgt package)
"Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context. "
(2) A preference element (the sharededatakey) is added to the config.xml
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
(3) A flatpack instance is then *detached from wookie* altogether and designed to be imported elsewhere?
Is there anything else a flatpack must do?
Results of testing....
freeder
=======
seems to inject the scripts as expected - but the start path refers to a wookie path.
wookiewiki
===========
<icon src="/widgets/www.getwookie.org/widgets/wiki/icon.png" />
<content src="/widgets/www.getwookie.org/widgets/wiki/index.html" type="text/html" encoding="UTF-8" />
<feature name="http://wave.google.com" required="true" />
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
The icon path & start page path are incorrect - the icon and start page are in the root of the new flatpack .wgt file. Also the wave feature has not been replaced with an actual JS implementation and is still present in the config.xml
Simplechat
========
Same issues as woookiwiki
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.2
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Commented] (WOOKIE-182) Flatpack: Allow exporting of
Widgets including instance information.
Posted by "Paul Sharples (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129606#comment-13129606 ]
Paul Sharples commented on WOOKIE-182:
--------------------------------------
I'm still a little confused about what a flatpack actually is or isn't.
Is a flatpack a mechanism for pointing back to an existing instance in wookie using a new .wgt package, or it is *detached from wookie* altogether and designed to be imported elsewhere, hence the injecting of wooke scripts?
The start page path (and icon paths) found in the new config.xml appear to point back to wookie, rather then the local start page in the new .wgt file. (minus the server url & /widgets rather then /wservices)
<content src="/widgets/wookie.apache.org/widgets/freeder/index.html" type="text/html" encoding="UTF-8" />
Some things are flatpacked, such as jquerymobile libs, but others such as the wave.js file are not.
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.1
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Updated] (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Scott Wilson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Wilson updated WOOKIE-182:
--------------------------------
Fix Version/s: (was: 0.9.2)
0.10.0
I think the remaining issues - like handling the Wave feature - are too deep to address in the next release, so punting to 0.10.0
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.10.0
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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
[jira] [Updated] (WOOKIE-182) Flatpack: Allow exporting of Widgets
including instance information.
Posted by "Paul Sharples (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WOOKIE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Sharples updated WOOKIE-182:
---------------------------------
Fix Version/s: (was: 0.9.1)
0.9.2
Moving to 0.9.2 - this is not a bloker, but there are a few bugs that need to be resolved.
Just for pointer when we come to review this again...
(1) Any wookie features are injected into the the new flatpack instance directly and removed from its <feature> element found in the config.xml (the new JS scripts are then included in the new .wgt package)
"Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context. "
(2) A preference element (the sharededatakey) is added to the config.xml
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
(3) A flatpack instance is then *detached from wookie* altogether and designed to be imported elsewhere?
Is there anything else a flatpack must do?
Results of testing....
freeder
=======
seems to inject the scripts as expected - but the start path refers to a wookie path.
wookiewiki
===========
<icon src="/widgets/www.getwookie.org/widgets/wiki/icon.png" />
<content src="/widgets/www.getwookie.org/widgets/wiki/index.html" type="text/html" encoding="UTF-8" />
<feature name="http://wave.google.com" required="true" />
<preference readonly="true" name="sharedDataKey" value="-984317104" /></widget>
The icon path & start page path are incorrect - the icon and start page are in the root of the new flatpack .wgt file. Also the wave feature has not been replaced with an actual JS implementation and is still present in the config.xml
Simplechat
========
Same issues as woookiwiki
> Flatpack: Allow exporting of Widgets including instance information.
> --------------------------------------------------------------------
>
> Key: WOOKIE-182
> URL: https://issues.apache.org/jira/browse/WOOKIE-182
> Project: Wookie
> Issue Type: New Feature
> Components: Parser, Server
> Reporter: Scott Wilson
> Assignee: Scott Wilson
> Fix For: 0.9.2
>
>
> The feature I've called "Wookie Flatpack" is for the use-case where a user has accessed a Widget Instance from within some sort of web platform (portal etc) but then wants to install the widget on a mobile device (or some other sort of device) instead. And by "the widget" what the user usually means is the widget *instance*.
> At the moment the only option is to clip the URL of the iFrame, navigate to it in the mobile browser, and then save the page as a bookmark app. Not great.
> So what I propose is to have a capability to on-the-fly generate a new .wgt package for the Widget Instance that the user can download and then side-load on their phone using something like the rather wonderful Opera WAC Runtime for Android [1].
> The "flat" bit is that rather than just downloading the .wgt package that was originally installed by the admin, Wookie generates a new, instance-specific .wgt file that includes the injected scripts that are specific to Wookie (such as the Wave feature) and removes their <feature> references from config.xml. It also embeds the context information (idkey, proxy_url) directly in the widget JavaScript code rather than expecting the scripts to pick it up from the browsing context.
> This means that rather than a generic widget, you'd get *your* instance of it. So we "flatten" the widget and the widget instance configuration and "pack" it into a single, one-shot .wgt package for that user's device.
> There are some things that need thinking about - for example securing the "flatpack" .wgt store so you can't hjiack someone else's widget instance. And managing the requests in a secure fashion. I think this could involve having the Connector Framework request a flatpack and then returning the URL for it along with a short-lived download key, and deleting flatpacks from the server itself after downloading or after an expiry time.
> We would also want to selectively not flatten some features - for example, we'd want to use the original <feature> elements for device APIs rather than include our flash/browser versions for things like camera capture.
> One issue is that the W3C Widget Interface isn't exactly the same as the WAC widget object used by mobiles (e.g. different method signatures for preferences). Not sure what would be the best solution there; maybe a shim in our Widget interface to delegate to WAC where its present?
> Also the user experience and documentation needs some thought.
--
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