Re: [Widgets] Mozilla open apps

Hi Mike,

On Wed, Oct 20, 2010 at 8:40 PM, Mike Hanson <mhanson@mozilla.com> 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.
> 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.
> 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.
> 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?
> 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?

Certainly not. We could happily have both:

If widget contains JSON manifest, use that. Otherwise, use the XML one.

Hopefully, we can just layer the JSON on top without breaking
backwards compat. I'm happy to discuss this further.

> 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

Sounds ok to me.

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

Congrats! :)

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



-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au

Received on Wednesday, 20 October 2010 19:04:43 UTC