On 7 July 2015 at 07:12, Jonas Sicking <[email protected]> wrote: > 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. >
I think I agree... we could deliver an MVP for pinning sites which provide a W3C manifest (or no manifest) without needing to use the Apps API or a new Gecko API, it's feasible to handle them entirely within Gaia. But how should we handle the case where the user navigates to a Firefox App in the browser (either a legacy hosted Open Web App or a new signed streamable packaged app), and then tries to pin it? Would we a) just pin it like a web site using metadata provided by the page and not provide any additional features, keeping the existing separate install flow in the Marketplace or b) require that all Firefox Apps provide a manifest link relation in their pages pointing towards a manifest with proprietary Mozilla properties, somehow detect the difference, then internally install the app via the exiting Apps API? I would have a strong preference for b), but I'm not sure how feasible that is from a BizDev/Evangelism point of view. We'd need to be clear on how this is going to work very soon to set those balls rolling. 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. > I agree, I think it's likely that 2.5 is going to be a bit of an in-between state where we support both models to some extent (hopefully we can hide that from users). In 3.0 we can hopefully unify things more at the platform level. > > 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. > I think you may have misunderstood me a little here, I was saying that we shouldn't require a manifest in order to be pinned, but we will use any metadata provided (including a manifest), and it's mostly Firefox Apps that Gecko needs to be made aware of. Ben
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
