tree 2e4f73a93d3b75f53f8326cc598a3906e0d5b64d
parent 637bc283b70e32f58a114f6232744ee5ae036c03
author Karl Rosaen <krosaen@google.com> 1249346320 -0700
committer Karl Rosaen <krosaen@google.com> 1249346541 -0700

Fix regressions in source mixing logic by going back to previous approach with a longer promoted source timeout.

Notes from bug 2031676:

some regressions i noticed illustrated by the following scenario:

- search for "ros"
- there are a bunch of contacts results, the first 3 of those are displayed
- after the deadline passes, the "search the web for 'ros'" entry is mixed in
- once the web results finally return, instead of mixing some of those results are in, the rest of the contacts are mixed in, and the web results show up under "more results"

1) if we are going to wait for all of the promoted sources to return, we should mix them into the promoted slots
(i think this is because the fixes last week were focusing on the case when the promoted sources that return early don't have any results...)

2) mixing in "search the web for" early is kind of odd, leaving it in an inconsistent place depending on how quickly the promoted sources return

3) if a promoted source takes forever to respond, sources under "more results" won't ever get shown; there is no effective timeout anymore, except for showing the "search the web" entry...

instead of the additional complexity of remembering the "late reporting" promoted sources and treating them differently, I think it would be simpler to just extend the deadline to something like 6 seconds.  this will have the same benefit of not pushing a lone "google results" entry under more results too often, while still preserving the notion of a timeout (even if it is a lot more generous now)

I think some of the changes in the past week to SourceSuggestionBacker were good, but at this point I think the
safest way to get back to a stable state is to revert to a known working point; we can reintroduce some of the
refactorings for calrity and performance if desired later on.