Re: [Widgets] Mozilla open apps

On 20 Oct 2010, at 19:40, Mike Hanson wrote:

> Hi there -
> 
> I can speak for the technical aspects of the Apps project and relay feedback as needed.
> 
> We had looked at the Widget Packaging spec earlier in the project and had steered away from it because we were focused on the "in-browser/live URL" use case.  But as we added icons, names, descriptions, and whatnot, we've converged back on something close to Widget Packaging.
> 
> So... I think, as you note, it's worth making the effort -- I propose that we try to figure out how to make the Widget spec fit our current use case, and, if it doesn't, see if we can find a small number of deltas that get us there.

Great! 

> I'll try to summarize the differences here:
> 
> 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".
> 
> We also intend to experiment with embedding URLs for service endpoints -- for example, a cross-document postMessage sink.  I don't see an element that we could adopt for that purpose yet; perhaps we could propose an extension.

In Apache Wookie we have several proposals for inter-widget communications (IWC). A good summary of existing approaches has been developed by Ivan Zuzak [1] and we are taking these forward through community contributions. In general we have found IWC to be sufficiently orthogonal to the core Widget packaging and APIs to be implemented using the existing Feature extension mechanism rather than needing anything special in the spec.

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

Update URLs are described in Widget Updates [2] - worth taking a look at.

Signatures are described in Widgets: Digital Signatures [3] - also worth a look.

I agree that "app store metadata" is also a useful thing to look at. Some time ago there was a discussion on this list of proposing some additions to the Atom Syndication Format for sharing app store listings, and it may be useful to revisit that.

> The gist of our approach (and the part that is really new, I think) is that JavaScript running in some web context can ask, "has the user installed an app for my domain?"   And then, further, "if the user has an authorization URL for my domain, load it now".
> 
> 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?

Apache Wookie also uses Widgets in the in-browser case. We just add our own parameters to the URL to identify the Widget Instance as opposed to the "canonical" widget URI.

In our case, the specific Wookie install (the "app store", whether generally open or enterprise-specific) is assumed to be trusted by the container (e.g. Wordpress, JetSpeed etc).  It is also responsible for providing the list of installed widgets to the container via a REST API [4] - is that the same sort of thing?

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

I can't see that being much of an issue. Though TBH the processing of the semantics of the package is more challenging than the syntax.

> 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.
> 
> We can't mandate a folder-based localization model since we are trying to describe existing web content.

In Wookie we use a servlet filter to return localized resources based on a user's specified locale without rewriting the URL. So it is doable.

> 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?
> 
> (Prior warning: I apologize if I disappear from the list at short notice in a day or two; I have a new baby coming imminently)

Congratulations! Save up your sleep now ;-)

[1] http://code.google.com/p/pmrpc/wiki/IWCProjects
[2] http://www.w3.org/TR/widgets-updates/
[3] http://www.w3.org/TR/widgets-digsig/
[4] https://cwiki.apache.org/confluence/display/WOOKIE/Wookie+REST+API

> 
> [1] http://code.google.com/chrome/apps/docs/developers_guide.html
> [2] http://www.w3.org/TR/2010/WD-api-perms-20101005/
> 
> Best,
> Mike
> --
> Michael Hanson, Mozilla Labs