On Wed, 19 Jun 2013 06:56:13 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:
On Tue, May 14, 2013 at 7:47 PM, Marcos Caceres <mcace...@mozilla.com>
wrote:
The current proposal can be found here:
http://manifest.sysapps.org/
I wonder to what extent we actually need a manifest. I think it's main
benefit might be in grouping a set of pages, but whether that needs to
be via a manifest I'm less sure about.
I think pretty much any mechanism that groups pages *is* a manifest. There
are lots of ways to make them, but given that most shipping solutions have
converged on something that looks a lot like the W3C widgets manifest
format (in XML), or something in JSON that is very similar, it seems
reasonable to assume that isn't a bad starting point.
A requirement that keeps coming back for web applications (i.e. those
served in a browser over HTTP, such as https://www.twitter.com/ ) is
that multiple of them per origin should be supported.
Yes.
Reasoning for this is simplicity of deploying new applications and to
some extent to reduce the number of DNS queries for a suite of
applications.
Downside of that approach is increased attack surface for a suite
applications
Can you please expand on that?
and no trivial boundary between them (given a URL it's not
clear to which application it belongs).
Well, it is true that a given URL might not be able to say what
application it belongs to. But then, it may not need to, or even be
desirable. To take silly examples, images rarely know what pages they are
part of and scripts often don't. That seems to be a feature, not a bug.
Navigation Controller solves the grouping of a set of pages using an
origin plus wildcard matching for a set of URLs, although as currently
proposed a subset of those URLs might be something else altogether
again, without much declarative control.
For event pages/workers you'll want something similar. To identify
what a URL's associated event page/worker is.
It might be though that maybe we should put the boundary for
applications on the web on the origin level. It would certainly be
extremely convenient and allow for a whole bunch of simplifications.
Yeah, but the price of enforcing origin-based restrictions on the Web is
that we break a lot of the "web"-ness. While there are security reasons
for doing so in many cases, I think the platform loses each time we build
such a restriction. The purpose of things like CORS is to reduce that cost
compared to the simplified case of a rigid same-origin policy, and I think
that's a pretty good thing.
just 2 kopecks
chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
