- From: Tony Gentilcore <tonyg@chromium.org>
- Date: Fri, 15 Oct 2010 09:17:55 -0700
On Fri, Oct 15, 2010 at 9:08 AM, Aryeh Gregor <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com> > wrote: > On Thu, Oct 14, 2010 at 2:59 PM, Peter Kasting <pkasting at google.com> > 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 <tonyg at chromium.org> > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101015/683c3360/attachment-0001.htm>
Received on Friday, 15 October 2010 09:17:55 UTC