Re: [manifest] Support for deep integrations, e.g. OpenSearch (#421)

> More of a concern for me is that this feature would put a requirement for the manifest to be downloaded on page load (possibly with a degree of priority, as presumably you want to make the search for a site available as early as possible 

That would be an optimization over the status quo, but likely not a requirement. Any user interaction with the omnibox (or other search-specific UI) would happen after the page has loaded. The chief advantage of this is that on subsequent visits, the user agent will already have cached the manifest & OpenSearch URL.

> Currently, loading the manifest early, or at all, is not a requirement because the manifest is used solely at install time and thus only needs to be lazily loaded when needed.

Agreed. Depends on how we define “install”. If we expand the definition to include “installing” a search provider, then this will need to happen at page load time (async, of course.)

The primary advantage will be consolidating all these individual resource definition XML files into a single coherent standard. There is no reason OpenSearch needs to stay a separate downloadable XML file if there’s already a manifest with a larger purpose being downloaded.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/421#issuecomment-176889371

Received on Friday, 29 January 2016 18:04:21 UTC