On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
<scott.bradley.wil...@gmail.com> 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.
I agree that it is worth returning to.
The TPAC meeting in Santa Clara might be a good chance to sit down in the
same place and talk about it as well as email, which is generally a better
way to clarify what the issues are but not always the most effective way
to solve the hard ones.
Are people likely to be in the Bay Area in the first week of November, and
prepared to spend a bit of time discussing this?
cheers
Chaals
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
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com