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
