[
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
