Hi Tim

> On 28.01.2019, at 02:23, tim Rowledge <tim at rowledge.org> wrote:
> 
> I'm really pleased some competent people are thinking about this; means I can stop worrying about something outside my main thrust ! 
> 
> Generally I prefer things to timeout very quickly if they are going to timeout at all - I was startled to see that the default timeout appears to be 45 seconds. This is especially the case if the thing potentially timing out is blocking any other actions I might want to be getting on with, it used to be a *real* annoyance with some RISC OS applications blocking the entire OS through poor design. Some better user feedback about the progress would help in a lot of cases. After all, if you have some indication that stuff is actually being done for you it is less annoying. It's a pity there isn't a class of html 'error' message that says "I'm working on it, busy right now, check again in X seconds"  or "we're sorry, all our sockets are busy. Please stay online and we'll get to you soon" etc.
> 
> I am interested in what error responses we might sensibly handle and how. Some examples that document helpful behaviour would be nice to add so that future authors have some guidance in doing smart things.
> 

Yeah, quick timeouts would be great, but we can't have them, somehow. One of the problems is latency that accumulates over the multiple hops your packages take.
Also, things like TCP timeouts have to be accounted for. This is all nontrivial now. I mean, in the US or all over Europe, we could probably do away with 10s timeouts max. But then things get complicated for African or South-american users, where the whole network latency can accumulate around that number PLUS overhead the sending app and receiving clients incur…

¯\_(ツ)_/¯



> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Oxymorons: Sweet sorrow
> 
> 
>