13:08 < lifeless> say it asked for - in order - 'r', 're', 'ref', 'refa'
13:08 < lifeless> but the answers come back in the order 'ref', 'refa',
're', 'r'
13:09 < lifeless> thats why it looks wierd
13:09 < lifeless> but more specific searches complete faster, so this is
actually expected
13:09 < beuno> yeah, probably because
13:09 < lifeless> now, imagine that in each answer you include the
search at the top of it
13:09 < beuno> 'r' took longer to process
13:09 < lifeless> so the answer for r will have 'I am a search for 'r'
13:09 < lifeless> and so on
13:10 < lifeless> then the client can do this:
13:10 < lifeless> if the current contents of the widget does not start
with the response, ignore it
13:11 < lifeless> if the contents do start with the response, and no
drop down is shown, store the thing the response is for in a variable
and show the drop down
13:11 < beuno> yes, that's one way to do it. But that would hammer the
servers pretty bad on a large scale
13:11 < lifeless> if a drop down is already shown, and the response is
for a shorter query than the drop down is, discard the response
13:12 < lifeless> beuno: this is not a replacement for asking less
often; its needed anyway (because under high load this can happen
anyway)
13:12 < beuno> lifeless, right, that makes sense
13:12 < lifeless> (oh, and if the user deletes terms, obviously reset
this variable or something
13:12 < beuno> so it should be a combination of both
13:12 < lifeless> yes
13:13 < beuno> ok, so *more* javascript to write :)
affects loggerhead
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
Half of this has been committed.
It now aborts requesting if the user types faster than 200ms per letter