On Wed, Jul 1, 2015 at 2:11 PM, Benjamin Francis <[email protected]> wrote: > On 16 June 2015 at 00:59, Jonas Sicking <[email protected]> wrote: >> >> We will definitely need a FirefoxOS-specific API which tracks the list >> of URLs that have been bookmarked, and which maybe caches manifest >> information as needed. Likely this API would also need to send >> notifications when pins are added/removed. > > I think this API is now the biggest unknown platform dependency for the Pin > the Web features for 2.5. > > I've been thinking about what this API might look like, and I've been > struggling to think of many ways in which it is different to the existing > Apps API in terms of its interface.
We currently have two registries: Apps and bookmarks. Things that go into the app registry are given additional permissions but are also put in a separate cookie jar. This cookie jar is extra aggressive given that anything linked from within the cookie jar stays within the cookie jar. Things that go into the bookmark registry stay within the browser cookie jar, but are not given additional permissions. What we *want* should happen when the user pins a website is: * Grant the origin unlimited persistent storage. This requires implementing at least the backend pieces of https://storage.spec.whatwg.org/#api as well as make localStorage run on the quota manager backend. * Grant ability to use Push, BackgroundSync and Alarm APIs. But right now these rely on signing and system messages. I'm somewhat reluctant to spend the effort to make these work for normal websites given that there are standardized versions of these based on ServiceWorkers coming soon. * *Maybe* grant the ability to use notifications. I'll leave this to the UX team. I think we have an opportunity to differentiate by creating a device which doesn't constantly notify you about crap you don't care about. * Register webactivities. * More aggressively update the ServiceWorker. * Do something for websites that use a display-mode and/or an orientation. It's a bit unclear to me what we should actually do here, especially for manifests that don't have a scope. However only the first one is really going to affect websites given that extremely few websites use any of the other features. So in practice, if we don't do any of this, and simply treat pins as bookmarks, there will be relatively few downsides. If, on the other hand, we stick pins in the application registry, the main thing that would immediately happen is that pinned content would get its own cookie jar. I.e. as soon as you pin something you'd get automatically logged out. We could definitely change that. But given the relatively few downsides of just using the bookmarks database I think we should do that for now. That way we'll have more freedom to modify what is stored since it can be handled entirely within Gaia. Once we have that more figured out, and once we have more of the new security model in place, it definitely sounds like a plausible option to simply use the apps registry to store pins. Part of that will definitely be to remove the existing data-jar-per-app policy that we currently have. That sounds like something that should fit in the 3.0 release without too much hassle. > We might say that the biggest difference is that a site no longer requires a > manifest in order to be pinned/installed. But all of the features we've > talked about which require Gecko to know about a pinned site actually > require a manifest anyway. I don't think that's true. We can get a nice-looking icon and a icon name using just <meta> and <title> tags. I would expect that that covers by far most of what people will put in the manifest. And there are *far* more websites out there that has that has apple-touch-icon <meta> information, than have manifests. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
