Re: [Widgets] Mozilla open apps

On Jun 28, 2011, at 20:17 , Scott Wilson wrote:
> I think Bruce Lawson was dropping a big hint the other day to look again at the questions Mike posed a long while ago! I know there was discussion at the time, but I think both initiatives have moved on somewhat so its worth returning to.

Thanks for picking this up, I think it is indeed a good idea.

> On 20 Oct 2010, at 19:40, Mike Hanson wrote:
>> In-Browser/"live content" usage
>> Our goal is to encompass "in-browser" application usage, where some subset of normal web browsing activity is identified as an "app".  
>> 
>> This means that we need to identify some subset of the URL value space that "belongs" to an app.  Our current approach (which is close to the one proposed by Google [1]) is to identify a URL set (Google allows regexes; we propose domain-matching with a path prefix).  Google proposes allowing a carve-out of "browsable URLs", which can be visited without leaving the app, presumably for federated login.
>> 
>> Specifically, this means that the content element would need to be replaced or augmented with some sort of app_urls or somesuch.  It also seems like the HTML5 App Cache proposal is addressing the same problem space as content; is there some way to harmonize all of this?  If we get this right we can perhaps get a smooth continuum from "live web site" to "dedicated brower instance" to "widget".

I certainly think that content could be augmented to point to a URI (and the configuration would then be sent on its own). I think that this matches some ideas discussed previously in which a widget could be endowed with an HTTP origin in order to function as if it had been acquired from that source. This could be achieved for instance by actually acquiring it from said source (and keeping track of that fact) or by using a signature properly tying the two together.

With that approach, the configuration document becomes just a way of describing an app, irrespective of whether it's on the web or on a USB key. AppCache is just a way of controlling the caching of content on the Web, so that the two are complementary. Then there's packaging: it would be really nice if it could be used for more than widgets, notably to package a set of resources (CSS, images, scripts, etc.) that can then be acquired with a single request, what's more compressed. This would not just help performance, it would also help with dependency management when you're fanning your content out to multiple servers and as the content is being deployed you hit stupid issues with v2447 of the CSS being loaded alongside v2448 of the script, which then causes hard to track user bugs (and gets even more amusing with caching involved).

This then leaves widgets as nothing more than a convention to have the configuration document at a specific location inside a package (oh, and some silly rules about content localisation).

>> Per-application metadata repository and access API
>> We propose that the "application repository" maintain some metadata that is in addition to, and along side, the manifest.  Specifically, an authorization URL, signature, installation location and date, and perhaps an update URL.

Have you looked at how this could integrate with PaySwarm for instance?

>> You could try to use the Widget API for this, but the trust model isn't exactly right.  Our intent is that the user has a trust relationship with a store or directory, and has a less trusted relationship with the app; the app does not discover the authorization URL, for example.  In our thinking this implies that there is a "app repository" object that has a couple methods; AFAIK there isn't an equivalent object that has the "list of all installed widgets" in the spec.  Am I missing something?

You're correct, this isn't part of the widgets family of specs. But it's something that could be considered. There currently only is access to information about the widget itself, not about the runtime in which it is executing.

>> XML vs. JSON
>> Cultural nit: many web developers have trouble with complex XML encodings.  It's frustrating, but true.  Would the specification of a JSON dialect be amenable, or is it that a non-starter?

The widget configuration hardly rates as "complex". That being said, it should be rather straightforward to produce a JSON alternative (and both could be accepted, with one taking precedence if both exist). My primary concern would be localisation. While I'm not particularly fond of the content localisation mechanism available in widgets, the configuration localisation is actually quite usable (and, I think, useful). I can think of ways of representing that in JSON, but they aren't particularly nice. At all.

>> Localization Model
>> The xml:lang based approach is structural analogous (though somewhat tedious to handle in JSON, but that's not really important).  In the absence of a content element, the folder-based localization strategy could hit some bumps.  Perhaps extending lang to a couple more elements would be sufficient - we are trying to fit into existing user-agent localization approaches, which might mean that we need to identify a different set of hostnames or launch URLs as well.

The localisation model could be limited to widgets. On the web, people can rely on CONNEG (if they're into that sort of stuff) or a host of other options. I wouldn't see this as a barrier, and if it provides reason to deprecate the localisation model in widgets, then so much the better.

> We use Widgets on a web server, and implement folder-based localisation using a server-side resource filter. I don't think rewriting requests for my.widget.site/index.html to my.widget.site/locales/fr/index.html based on HTTP locale headers ought to be a big challenge for a server-based UA.

Maybe not, but that requires server-side infrastructure which I don't think we should be imposing on people just to create a web application.

>> Widget features we can adopt 
>> I think name, description, author, license, icon, and feature are all straightforward enough.  Is the assumption that the value space of feature is going to be the W3C Permissions set [2], or something else?
>> 
>> [2] http://www.w3.org/TR/2010/WD-api-perms-20101005/

I would fully assume that the value space for Permissions (now at http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html) would be the same as found here.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 30 June 2011 12:08:10 UTC