[
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
