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.
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
^^^^ Note replying here to an old post for context
> 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.
Looking at Mozilla Open Web Application (MOWA) and Widgets today, I don't see a
big issue here. If you host a Widget manifest with or without a <content>
element it would behave rather like a MOWA manifest. E.g., if there is no
<content src="blah"> or no {launch_path: blah} you would use the default. In
the case of MOWA this is the origin of the manifest, in the case of Widgets it
would be /index.html (etc).
I guess there isn't any guidance on "naked" Widget manifests as such, but I've
always assumed this would be possible/supported. If we write a Note on "web
apps" we could put it there.
>
> 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?
This looks quite similar to the REST APIs that Apache Wookie exposes, though we
don't make them available within the Widget context itself. I think its quite
specific to a type of Widget store model rather than the Widgets/Apps
themselves, and it does seem a bit strange to access them via the running app
script context rather than addressing the server directly. In any case, there
is useful functionality in MOWA (e.g. the "install" function could download the
actual .wgt, rather like the Opera Widgets site, or be overridden with
implementation-specific behaviour) but it doesn't feel like its either within
the scope of Widgets itself nor a blocker for MOWA using Widgets. Indeed, the
MOWA APIs themselves could be exposed as <feature>s, or directly injected into
applications regardless if running on a MOWA-capable Widget server.
>
> 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?
JSON makes it a little bit easier to implement a UA, and a little bit harder to
write a widget manifest in a text editor. If you are writing some sort of app
store you could easily generate any representation you fancied supporting based
on the requested content-type (JSON, XML, YAML, RDF...) So I don't think its a
big spec issue. (This might be part of a Note for web apps - e.g. MUST support
getting the manifest as XML, SHOULD support getting it as JSON, MAY support any
other formats.)
>
> 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.
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. The only
problem you would face is with purely static file servers, where the developer
also has no way of creating a server rewrite or forwarding rule.
> 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)
>
> [1] http://code.google.com/chrome/apps/docs/developers_guide.html
> [2] http://www.w3.org/TR/2010/WD-api-perms-20101005/
Features/capabilities was dropped from later versions of MOWA.
In general I don't think there are any serious barriers to implementing Mozilla
Open Web Apps directly using Widgets as-is. A lot of the value-add for MOWA is
in the app repository trust model that seems outside the scope of the Widget
itself - this looks a bit odd bolted onto the manifest but looks great as the
starting point for a broader "app repository/federation" spec regardless of the
flavour of apps involved (Widgets, MOWA, OpenSocial... add 17 others here). So
maybe one way forward is for Mozilla to promote these specific
features/use-cases in the Federated Social Web activity.
In any case I think looking at where we are now its more a case of "Widgets +
MOWA" rather than "Widgets or MOWA": in other words, MOWA could be rather like
WAC in taking the Widget specs and developing standardised services and
identity/trust rules for implementers. I think if I were so inclined I could
make Wookie into a MOWA store for serving Widgets without any big architecture
changes, for example.
Anyway, sorry for reviving a dead thread, but thought it might be of interest.
S
>
> Best,
> Mike
> --
> Michael Hanson, Mozilla Labs
