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
smime.p7s
Description: S/MIME cryptographic signature
