Wookie Flatpack

[Scott Wilson <sc...@gmail.com>]

Hi everyone,

We're working on two big projects at the moment that use Wookie - one involving mobile/telcos and another involving interactive whiteboards etc* - and from some discussions with partners in those projects about their requirements I've come up with an initial idea for a new feature. 

The feature I've called "Wookie Flatpack" and 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.

Anyway, what do you think?

S

[1] http://labs.opera.com/docs/wac/installation_instructions/

* Hey Jean-Noel & Hoang Minh Tien! If you're reading this, say hi :-D

Re: Wookie Flatpack

[Scott Wilson <sc...@gmail.com>]

On 9 Feb 2011, at 17:14, Ross Gardler wrote:

> On 09/02/2011 15:32, Scott Wilson wrote:
>> 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].
> 
> I started to implement a similar feature the other day, but it was too complex. I just wanted to pull down the original .wgt file from which the widget was deployed. This proved to be quite complex as we don't currently keep a record of what comes from where and implementing this cleanly seemed to be quite cumbersome. I felt I needed to ask the list for pointers, but have yet to find the time to do so.
> 
> I then thought about writing a quick hack whereby we iterate over the widget instances, open them up, match the names and serve as appropriate. This would work and, with some server side caching, need not be inefficient.
> 
> The reason I did not consider building a fresh .wgt file is because Wookie does some URL munging and other tricks on deployment. It looked to me that a .wgt generated from the Wookie runtime files would not run on a standalone device.
> 
> Your proposal seems to go further than this though. You are talking about deployment of instances as opposed to widgets. I can see how this would add significant value to my own use case (simply to deploy widgets on the desktop using Opera).

Its certainly not as trivial as I may have presented it! 

One way I was thinking of this was to hold the reference to the original .wgt file in the Widget object and then when creating a flatpack we pull it into the parser module again, but using a different implementation of the IStartPageProcessor (or a similar post-processing interface), and then outputting it using a widget writer class (which something I was thinking of adding to the parser anyway - a one-way parser is a bit limited).

>> 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.
> 
> I like the idea.
> 
>> 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.
> 
> That doesn't solve the problem of someone getting hold of another persons flatpack (or appropriate ids) after it as been legitimately deployed. Can each flatpack be keyed to a specific device/runtime environment?
> 
> This would require a separate flatpack for each device the user wants to run the widget on, but that doesn't seem to be a major disadvantage.

That is definitely an issue. I can't think of an obvious answer to that right now. I'll have a look in the WAC specs - there may be something there that could help.

>> 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?
> 
> Are there any moves at the specification level to resolve this? It seems like it is something that needs to be addressed at that level and anything we do here will be an intermediate step.

I think its because when Vodafone/JIL adopted the spec originally it was when it was in a really early draft and as they got everyone using that, they've basically forked the API spec in WAC. I can imagine at some point in the future they might move to the current spec - I'll ask around and see what the plans are as it would be good not to have to put in a hack for this.

> 
>> Anyway, what do you think?
> 
> +1
> 
> Rpss

Re: Wookie Flatpack

[Scott Wilson <sc...@gmail.com>]

OK, I've just committed the last of a series of changes to implement this new feature in basic form! 

I'm sure its got a ton of bugs, but I've put in quite a few tests. Please do play with it* and report any issues. Basically you invoke it rather like the WidgetInstances API - the POST request has the same parameters (but is located at /export) - what you get back is just the URL to the .wgt you can download. See the test cases for an example.

On 9 Feb 2011, at 17:14, Ross Gardler wrote:
> 
>> 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?
> 
> Are there any moves at the specification level to resolve this? It seems like it is something that needs to be addressed at that level and anything we do here will be an intermediate step.

Some good news on this one - see http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/core/web-standards.html

Quote:
> 2.7.2. Widget Interface
> 
> The Widget Interface [Widgets-APIs] defines key APIs used by widgets, e.g. for managing widget private storage.
> 
> WS-1400 The WRT MUST implement the Widget interface in accordance with the [Widgets-APIs] specification.

So this means the WAC injection stuff I just committed this afternoon is already supporting legacy WRTs :-)

[OK code sprint over for now, time to get a drink and to pay some attention to my girlfriend!]

- S

* AFTER you've tested the 0.9.0 release, obviously!

Re: Wookie Flatpack

[Ross Gardler <rg...@apache.org>]

On 09/02/2011 15:32, Scott Wilson wrote:
> 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].

I started to implement a similar feature the other day, but it was too 
complex. I just wanted to pull down the original .wgt file from which 
the widget was deployed. This proved to be quite complex as we don't 
currently keep a record of what comes from where and implementing this 
cleanly seemed to be quite cumbersome. I felt I needed to ask the list 
for pointers, but have yet to find the time to do so.

I then thought about writing a quick hack whereby we iterate over the 
widget instances, open them up, match the names and serve as 
appropriate. This would work and, with some server side caching, need 
not be inefficient.

The reason I did not consider building a fresh .wgt file is because 
Wookie does some URL munging and other tricks on deployment. It looked 
to me that a .wgt generated from the Wookie runtime files would not run 
on a standalone device.

Your proposal seems to go further than this though. You are talking 
about deployment of instances as opposed to widgets. I can see how this 
would add significant value to my own use case (simply to deploy widgets 
on the desktop using Opera).

> 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.

I like the idea.

> 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.

That doesn't solve the problem of someone getting hold of another 
persons flatpack (or appropriate ids) after it as been legitimately 
deployed. Can each flatpack be keyed to a specific device/runtime 
environment?

This would require a separate flatpack for each device the user wants to 
run the widget on, but that doesn't seem to be a major disadvantage.

> 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?

Are there any moves at the specification level to resolve this? It seems 
like it is something that needs to be addressed at that level and 
anything we do here will be an intermediate step.

> Anyway, what do you think?

+1

Rpss