On Tue, Jun 16, 2015 at 12:02 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. > > Any idea who might work on this API? What are the next steps?
I think anyone with gecko experience could. I think we generally should stop worrying about the exact nature of "sensitive APIs", i.e. APIs that are sensitive enough we can't expose them to unsigned content. And this falls into that category. APIs that require signature stand no chance of getting standardized within the next few years, and I think that's ok. I am definitely one of the primary people that has been overly concerned about getting these types of APIs exactly right, but I think that has been a mistake on my part. But could we perhaps simply use a DataStore here for now? And have the system app responsible for checking for and downloading updated manifests. The system app could even download the necessary icon files and stick them as Blobs in the DataStore. >> One thing that is tricky is that in the new manifest spec the manifest >> URL is meaningless. In order to update an icon we need to re-download >> the HTML file and see what manifest URL it points to. >> >> This is especially problematic if the user "pinned the website" rather >> than "pinned the page", i.e. if we bookmarked the start_url rather >> than the current page URL. What do we do if the page on the start_url >> doesn't link to a manifest? Or links to a different manifest? Does the >> spec address this? > > Yeah this is annoying. But thinking about this, do we actually need to fetch > the page on every update? The spec says you can just fetch the manifest URL > [1]. That's a poor suggestion by the spec. By encouraging the manifest to be hosted on a CDN, we should expect that developers will change the manifest URL any time the manifest content changes. While the spec might allow refetching the manifest only, it will definitely cause users to use an outdated manifest. > We definitely need to check the start_url in the manifest is same > origin with the document the manifest is referenced from at "pin" time, but > after it's pinned do we need to keep checking that on every update? We could > just keep a record of the URL the site was pinned from to do these checks on > update, or make sure the origin of the start_url never changes. I suspect that if the user chooses to bookmark the start_url, then we should simply refetch the HTML page at the start_url every time we want to look for an updated icon. I don't think this refetching is a big deal though. > We do need an API for Gaia to tell Gecko to fetch a manifest with a > particular browsing context (I proposed a getManifest method on the Browser > API in bug 1169633). Given that we are getting rid of different cookie jars for different "apps", I don't think using the right browsing context is particularly important any more. I'm still totally fine with having gecko do the fetching if that's simpler. Another alternative is to have the system app do it. >> But yes, I'm sure we'll need APIs for managing the list of installed >> addons exposed to various gaia apps, like settings and system app. And >> we'll need to expose something to the amo website as well. >> >> > * datastores-owned/datastores-access (I hope we can deprecate DataStore >> > eventually but we need it for now) >> >> I'm hoping that we can deprecate DataStore as well. In the meantime I >> don't think we should expose it to privileged content. Hence I think >> we can do whatever we need to here in order to keep allowing Gaia to >> work. No need to be overly concerned about the APIs. > > We need a solution for the new privileged homescreen app accessing the > pinned sites/places Data Stores. I'd suggest that either we need to allow > privileged apps with the "homescreen" role to access Data Stores, or come up > with a Data Store replacement pretty sharpish. I suggest we use a DataStore for now. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
