Todd Pederzani writes:
> Fredrik Tolf wrote:
> > >Nah, I'm not sure about that. What if the user accidently presses
> >enter like 10 times (has happened to me from time to time when I'm so
> >tired that I think I let the button up completely, but in fact, it's
> >still down and autotyping)? Then all of a sudden the user must wait
> >for like 2 minutes two search again.
>
> Even better: 10 duplicate searches?  Send only one.

Well, like I said, it was accidental. It can also happen for other
reasons. Say that a hub connection is really laggy, so the user
presses the search button, but nothing happens, so he/she thinks that
it was registered for any reason, so the user presses again, and
again. By the time the hub has relayed the first search, there are 1
or 2 others in transit, that will remain queued, taking up unnecessary
time.

> >I think that it's better to make the hub warn, and then if the user
> >wants delayed searches, that can be implemented in the client instead.
> Or... it could be implemented in both places.

Why? The thing is that if you implement it in the hub, the user
_cannot_ cancel delayed searches, unless you add yet another command
precisely for cancelling delayed searches. If it is only implemented
in the client, it gives the user greater control. It's not like it
gives any advantages to have the hub queue delayed searches if the
client can do it instead.

Fredrik Tolf