[whatwg] SearchBox API

[Tony Gentilcore]

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-0002.htm>