Re: Kickoff application manifest work

On Jun 19, 2013 6:57 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> On Tue, May 14, 2013 at 7:47 PM, Marcos Caceres <mcaceres@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.

There's also the ability to provide "application"-wide information such as
icon, name and developer information. And information about which
intents/activities the application can handle.

I could also see wanting to stick more complex patterns for
navigationcontroller scopes in a separate manifest. I suspect that the
current prefix matching is going to be found to not be enough.

And if we want to enable event pages/workers to have synchronous access to
its visible tabs, then a manifest could be used to describe the scope of
that event page/worker such that the UA can make sure to put all relevant
tabs in the same process.

I believe the development model for web apps will be a lot simpler if the
application logic and application UI can communicate synchronously.

All of this information can of course be duplicated in each HTML page that
an application consists of. But that's a lot of information duplication. It
would definitely put some hard requirements on that generation of HTML
pages is always done using code of some sort. Either make files or server
side scripts.

We could also enable pages to signal this information through an API to the
UA. That way they author can put the information in a central location
himself. But that also means that the metadata can't be found through
spidering.

> 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. 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
> and no trivial boundary between them (given a URL it's not clear to
> which application it belongs).

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

There are two, maybe three main issues we have run into with only allowing
one "application" per origin.

* There is a lot of existing content that would have to be broken out into
several domains.
* It means that we can't allow simpler interaction between apps that are
from the same origin. For example the Google docs and gmail apps could
share a database which store attachments.
* Google puts most of their apps under www.google.com. I've heard that this
is an intentional policy, though I'm not sure why the policy is in place.
Potentially this is nothing important or the same as one of the other two
bullets above. Hence the "maybe three".

It would also be interesting to know *why* the content from the first
bullet is in the same origin. We should be careful whenever we
intentionally force people to do things differently than they are.

/ Jonas