On Fri, Oct 15, 2010 at 9:08 AM, Aryeh Gregor <[email protected]<simetrical%[email protected]> > wrote:
> On Thu, Oct 14, 2010 at 2:59 PM, Peter Kasting <[email protected]> > wrote: > > This proposal is not by any means the totality of everything involved > with > > "instant"-style support. It is only a piece. > > It's hard to evaluate a proposal that doesn't actually do anything by > itself. I don't see any problems in principle with this approach, but > it's impossible to say for sure without a full proposal. It could be > that this approach forces problems in other parts of the design which > aren't evident yet. > > On Thu, Oct 14, 2010 at 7:53 PM, Tony Gentilcore <[email protected]> > wrote: > > This is a good point that wasn't in the initial API proposal. The page > > needs to advertise support for instant. But the decision is more > > complicated that simply "provider A supports it and provider B > > doesn't." The Google SERP determines on a case-by-case basis whether > > instant is supported. For instance, for users with a high RTT time, we > > don't advertise instant support because it would be a bad experience. > > How does Chrome figure this out at present? Does it include hardcoded > heuristics like checking the RTT to google.com itself? Does it > optimistically assume that the feature should be used, so fetch the > page, then discard it if the page somehow says not to use it? > Something else? > The app has the heuristics. The UA fetches the page and discards it if the page doesn't indicate support. As pointed out this is suboptimal. Perhaps we need a two phase indication of support. First OpenSearch indicates that the page might support it, then the page itself has a chance to deny support on a per-request basis. > > > Yes, the API requires a bit of imagination at this point. I'll write > > up conformance requirements in more detail, but thought it worthwhile > > to get high level feedback and gauge interest first. > > Feedback from other search vendors would be particularly essential > before this becomes standardized, I'd think. Possibly other search > engines would have somewhat different takes that would require a > different API. > Agreed. That is exactly what I'm trying to elicit.
