SOP for expected Timeout?

[Kenny]

Suppose one has a Web app where under certain circumstances a server
will take 10 seconds to come up with an answer.

The crummy library I am using times out at 5s by default. Here are the
options I see:

1. Increase the timeout

2. Don't ask the server to do so much all in one bite (I can readily
chop the one request up into smaller bits).

3. Ask the user if they want to wait after 5s.

#2 is feasible but a nuisance. Is #1 rude to the user, aka bad form for
well-behaved web apps?

Did I miss a #4?

kt

 

[Erwin Moller]

Kenny schreef:

Suppose one has a Web app where under certain circumstances a server
will take 10 seconds to come up with an answer.

The crummy library I am using times out at 5s by default. Here are the
options I see:

1. Increase the timeout

2. Don't ask the server to do so much all in one bite (I can readily
chop the one request up into smaller bits).

3. Ask the user if they want to wait after 5s.

#2 is feasible but a nuisance. Is #1 rude to the user, aka bad form for
well-behaved web apps?

Did I miss a #4?

Yes,

Don't use a crappy library.

Erwin Moller

PS: Are you going to use my answer now to push your new pure JS FRP
framework as a solution to this problem?

kt

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Kenny]

Kenny schreef:



Yes,

Don't use a crappy library.

Are you saying your un-libraried requests do not time out?
Hmmm...

anyway, I incresed the timeout to 10s and invited them to try again (the
server caches the slow computations so it succeeds on the second try).

Erwin Moller

PS: Are you going to use my answer now to push your new pure JS FRP
framework as a solution to this problem?

Now you are harrassing me for offering a pure JS library? Bad show, old
chap.

p,k

 

[Erwin Moller]

Kenny schreef:

Are you saying your un-libraried requests do not time out?
Hmmm...

Well written JS can do little about a server timing out.
Poorly written JS and crappy JS libs will only add to the missery.

anyway, I incresed the timeout to 10s and invited them to try again (the
server caches the slow computations so it succeeds on the second try).

Why Kenny, why then do you ask in here?

What POSSIBLY use will the above 'technical information' ever have on
anybody who reads it?
Do you think increasing the timeout in your application is rocketscience
and people who find themselfs in similar situations are sooooooo happy
they find your enlightened solution for this hard problem?

[scene from high-tech development team in 2012]
Developer1: "My JS app times out because the server is so slow! What to do?"
Developer2: "I found the solution! Kenny wrote on 3 dec 2008 in c.l.j
the solution to our problem: We must increase the timeout in the
application! Wow!"

Now you are harrassing me for offering a pure JS library? Bad show, old
chap.

Which pure JS-lib are you excactly referring to?

And no, I harrass you because you annoy me and propably 99% of the
readers of this group judging by the warm welcome your postings receive.
Are you so stupid you didn't notice that?

Erwin Moller <-- adding to the crap posted here. I know.

p,k

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[The Natural Philosopher]

Kenny schreef:

Yes,

Don't use a crappy library.

Erwin Moller

PS: Are you going to use my answer now to push your new pure JS FRP
framework as a solution to this problem?

and #5, don't use a crappy server, or tune your serverside code.

 

[The Natural Philosopher]

Kenny schreef:

Are you saying your un-libraried requests do not time out?
Hmmm...

Well written JS can do little about a server timing out.
Poorly written JS and crappy JS libs will only add to the missery.

anyway, I incresed the timeout to 10s and invited them to try again
(the server caches the slow computations so it succeeds on the second
try).

Why Kenny, why then do you ask in here?

What POSSIBLY use will the above 'technical information' ever have on
anybody who reads it?
Do you think increasing the timeout in your application is rocketscience
and people who find themselfs in similar situations are sooooooo happy
they find your enlightened solution for this hard problem?

[scene from high-tech development team in 2012]
Developer1: "My JS app times out because the server is so slow! What to
do?"
Developer2: "I found the solution! Kenny wrote on 3 dec 2008 in c.l.j
the solution to our problem: We must increase the timeout in the
application! Wow!"

Erwin is the dogs nuts as usual..

Hint: I had a server script that was taking 10 seconds. Most of which
was SQL searching through a 1000 item database, 100 times, looking for
bits that matched a selection on one if its fields. An index on that
field reduced the server script time to 250ms.

 

[Erwin Moller]

The Natural Philosopher schreef:

Kenny schreef:

Erwin Moller wrote:
Kenny schreef:

Suppose one has a Web app where under certain circumstances a
server will take 10 seconds to come up with an answer.

The crummy library I am using times out at 5s by default. Here are
the options I see:

1. Increase the timeout

2. Don't ask the server to do so much all in one bite (I can
readily chop the one request up into smaller bits).

3. Ask the user if they want to wait after 5s.

#2 is feasible but a nuisance. Is #1 rude to the user, aka bad form
for well-behaved web apps?

Did I miss a #4?


Yes,

Don't use a crappy library.

Are you saying your un-libraried requests do not time out?
Hmmm...

Well written JS can do little about a server timing out.
Poorly written JS and crappy JS libs will only add to the missery.

anyway, I incresed the timeout to 10s and invited them to try again
(the server caches the slow computations so it succeeds on the second
try).

Why Kenny, why then do you ask in here?

What POSSIBLY use will the above 'technical information' ever have on
anybody who reads it?
Do you think increasing the timeout in your application is
rocketscience and people who find themselfs in similar situations are
sooooooo happy they find your enlightened solution for this hard problem?

[scene from high-tech development team in 2012]
Developer1: "My JS app times out because the server is so slow! What
to do?"
Developer2: "I found the solution! Kenny wrote on 3 dec 2008 in c.l.j
the solution to our problem: We must increase the timeout in the
application! Wow!"

Hi Philosopher,

Erwin is the dogs nuts as usual..

'The dogs nuts'?
I don't know that expression, but it sounds good.
I am unsure if I want to be the dogs nuts though. ;-)

Hint: I had a server script that was taking 10 seconds. Most of which
was SQL searching through a 1000 item database, 100 times, looking for
bits that matched a selection on one if its fields. An index on that
field reduced the server script time to 250ms.

This Kenny guy is an annoyance.
He seems to be pushing his great pure-js-yet-to-be-published spreadsheet
thingy and think we care.
I want to give him a misserable time while he is selling in here, under
the pretext he is giving useful info.

Regards,
Erwin Moller


--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[The Natural Philosopher]

The Natural Philosopher schreef:

Kenny schreef:
Erwin Moller wrote:
Kenny schreef:

Suppose one has a Web app where under certain circumstances a
server will take 10 seconds to come up with an answer.

The crummy library I am using times out at 5s by default. Here are
the options I see:

1. Increase the timeout

2. Don't ask the server to do so much all in one bite (I can
readily chop the one request up into smaller bits).

3. Ask the user if they want to wait after 5s.

#2 is feasible but a nuisance. Is #1 rude to the user, aka bad
form for well-behaved web apps?

Did I miss a #4?


Yes,

Don't use a crappy library.

Are you saying your un-libraried requests do not time out?
Hmmm...

Well written JS can do little about a server timing out.
Poorly written JS and crappy JS libs will only add to the missery.


anyway, I incresed the timeout to 10s and invited them to try again
(the server caches the slow computations so it succeeds on the
second try).

Why Kenny, why then do you ask in here?

What POSSIBLY use will the above 'technical information' ever have on
anybody who reads it?
Do you think increasing the timeout in your application is
rocketscience and people who find themselfs in similar situations are
sooooooo happy they find your enlightened solution for this hard
problem?

[scene from high-tech development team in 2012]
Developer1: "My JS app times out because the server is so slow! What
to do?"
Developer2: "I found the solution! Kenny wrote on 3 dec 2008 in c.l.j
the solution to our problem: We must increase the timeout in the
application! Wow!"

Hi Philosopher,

Erwin is the dogs nuts as usual..

'The dogs nuts'?
I don't know that expression, but it sounds good.
I am unsure if I want to be the dogs nuts though. ;-)

Well the actual phrase is the 'dog's bollocks' or sometimes the 'cat's
whiskers'. Where it comes from I do not know, but I think that this ->
:- is sometimes called that in the printing world.


Yep

More chapter and verse here..
http://www.phrases.org.uk/meanings/dog's bollocks.html

QI equated it with a spoonerism of the 'box de luxe'

This Kenny guy is an annoyance.
He seems to be pushing his great pure-js-yet-to-be-published spreadsheet
thingy and think we care.

well thats always the case. Theres a million things I can thnk of t
write in javascript taht the word definitely needs, but just doesn;t
know it yet ;-)

But until they are written, I'll keep 'schtumm'.

(There's another one for you).

I want to give him a misserable time while he is selling in here, under
the pretext he is giving useful info.

Oh, I think he can manage that all by himself..

 

[Kenny]

and #5, don't use a crappy server, or tune your serverside code.

Oh, believe me, we are doing that. Maybe I pay too much attention to
quality, but once I run into something like this I tune the server /and/
teach my apps to be more robust in the face of server malfeasance.

kt

 

[Kenny]

This Kenny guy is an annoyance.

Your cup is full.

He seems to be pushing his great pure-js-yet-to-be-published spreadsheet
thingy and think we care.

Just trying to help. It does make programming a lot easier. And it ain't
just me. Google for Sean Parent (sp?) talking at Google about Adobe
Adam, July 25th 2007 (might be off by one on the year). Same thing,
except for C++. Or check out OpenLaszlo, they do the same. Not as well
as me, of course.

hth,kxo

 

[Brian Adkins]

This Kenny guy is an annoyance.

What's annoying is reading your totally-void-of-useful-content
posts. Please stop, or take your complaints elsewhere. This is not
your private blog, it's a public forum about JavaScript. An angry,
bitter, vocal minority does not speak for all of c.l.js.

Why don't you try this - instead of improving your skills in
complaining, maybe you could provide some useful info about
JavaScript.

He seems to be pushing his great pure-js-yet-to-be-published
spreadsheet thingy and think we care.

I care more about dataflow in JavaScript than I do about you
attempting to emulate your teacher.

I want to give him a misserable time while he is selling in here,
under the pretext he is giving useful info.

'selling' ? How much is he asking for ?

 

[Erwin Moller]

Kenny schreef:

Your cup is full.

Sorry Kenny, I admit I pushed that too far.
My appologies for that.
I shouldn't have written like that.
I was out of line, etc.

Sincerely: Please go on with the project, I have no clue if it will be
good or bad (I wrote that before).
But I still think you should try to post one (not multiple) coherent
message about your project. The way it is presented now really resembles
spam, and is hard to understand.
I don't want to suppress you enthousiasm.

So sorry for my harsh words, and have a (virtual) beer on me.
I'll behave better from now on. ;-)

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Erwin Moller]

Brian Adkins schreef:

What's annoying is reading your totally-void-of-useful-content
posts. Please stop, or take your complaints elsewhere. This is not
your private blog, it's a public forum about JavaScript. An angry,
bitter, vocal minority does not speak for all of c.l.js.

Thank you.
I couldn't agree more (even wrote that myself earlier).
If I offended you too in the process: my appologies.

Why don't you try this - instead of improving your skills in
complaining, maybe you could provide some useful info about
JavaScript.

I do so on a regular basis, which you can easily check.
My (possibly) useful responses tend to appear in other threads than the
ones started by Kenny lately.
And besides that: I have to try my complaining skills somewhere to
improve them.

I care more about dataflow in JavaScript than I do about you
attempting to emulate your teacher.

Did you pick up anything that actually addresses dataflow in JS in this
thread and the other 'Qooxdoo does Cells!!!!! (almost)'?

I can't make head or tails of it.
Maybe it is just me.

But I agree I was too harsh to Kenny.
Not my usual style.
(I just send him a message with my appologies)

If I offended you (or anybody else) too, my appologies.
That was not my intention.

Regards,
Erwin Moller


--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Kenny]

Kenny schreef:



Sorry Kenny, I admit I pushed that too far.
My appologies for that.
I shouldn't have written like that.
I was out of line, etc.

No problem! I am on Usenet all the time, I adjust to the occasion.

Sincerely: Please go on with the project, I have no clue if it will be
good or bad (I wrote that before).

Well that is why I referenced other folks such as Sean Parent talking to
Google about Adobe Adam, or Flapjax, or OpenLaszlo. You'll see those
folks ranting about FRP aka dataflow aka linear constraints, too. Thems
of us who have used it cannot help sharing, it is so cool (and
productive and fun and even somewhat optimizing even with the overhead).
Prior art may go back to Sutherland's SketchPad and 1963 depending on
how you assess that tool.

But do not feel bad: Parent seems to have no luck getting Google excited
(they asked him why he was using C++, IIRC, instead of Haskell) and I
get about one user a year over in the Lisp world (but they are great
ones!) -- just when I think I am crazy my one new user a year comes
along and goes batshit over it. Go figure.

But I still think you should try to post one (not multiple) coherent
message about your project. The way it is presented now really resembles
spam, and is hard to understand.
I don't want to suppress you enthousiasm.

So sorry for my harsh words, and have a (virtual) beer on me.
I'll behave better from now on. ;-)

Beer sounds good!

peace, k

 

[David Mark]

Brian Adkins schreef:



Thank you.
I couldn't agree more (even wrote that myself earlier).
If I offended you too in the process: my appologies.

Don't feed that troll. Kenny *is* a spammer and you had every right
to call him on it. I see an off-topic half-wit telling you that you
are off-topic (and arguing for the silent majority.) Just ignore him
as his only goal is to keep the useless conversations going.

I do so on a regular basis, which you can easily check.

Don't respond to such nonsense. This from somebody who posts
*nothing* but flame-bait.

My (possibly) useful responses tend to appear in other threads than the
ones started by Kenny lately.
Obviously.

And besides that: I have to try my complaining skills somewhere to
improve them.

See what I mean?

Did you pick up anything that actually addresses dataflow in JS in this
thread and the other 'Qooxdoo does Cells!!!!! (almost)'?

Of course not. That thread was incomprehensible and the only subject
was that lousy framework.

I can't make head or tails of it.
Maybe it is just me.
No.


But I agree I was too harsh to Kenny.

No. Best to point out spammers/trolls/liars so that others can avoid
them.

Not my usual style.
(I just send him a message with my appologies)

He'll frame it. They are trying to waste your time and you are
letting them.

[snip]

 

[Gregor Kofler]

Erwin Moller meinte:

But I agree I was too harsh to Kenny.
Not my usual style.
(I just send him a message with my appologies)

Oh puhleeze! This guy is begging for abuse. (Unless of course you
haven't tucked him away in your filter.)
Annie Lennox already knew it years ago "...some them want to abuse you,
some of them want to be abused..." (Ah, nice music in the background
makes the recent proceedings on c.l.js so much more bearable.)

If I offended you (or anybody else) too, my appologies.
That was not my intention.

Come on. Mr. Tilton is a permanent PITA to the one responding to him -
and he never thought about an apology.

Gregor

 

[Kenny]

Erwin Moller meinte:



Oh puhleeze! This guy is begging for abuse.

Then how do you explain the filter I am building over here?

(Unless of course you
haven't tucked him away in your filter.)
Annie Lennox already knew it years ago "...some them want to abuse you,
some of them want to be abused..." (Ah, nice music in the background
makes the recent proceedings on c.l.js so much more bearable.)

Jeez, you are bad at music, too: that was the only song on the Unplugged
album that sucked.

Come on. Mr. Tilton is a permanent PITA to the one responding to him -
and he never thought about an apology.

If someone serious about software (http://smuglispweeny.blogspot.com/)
does no more than discuss a JS framework in a JS group and that causes
mass hysteria I would worry more about the hysterics than the serious
developer.

Meanwhile back on the JS front I just had a nice experience with
qooxdoo. After a misunderstanding with the client I chopped out a module
here and a component there to produce a leaner prototype to be polished
to the extreme before going back to reincorporate the other stuff. Then
they said, hey, where did the other stuff go? Super. I could send them
their email, or...

Along the way I had first leveraged their OO-lite mechanism to divide up
the code and then leveraged the simple message system to decouple
things, so I just lumped the stuff back in, brought one older component
up to speed on the new messaging approach and the frickin thing Just
Worked on like the fifth try. An hour later the reconstitued prototype
was reinsatlled.

Sweet.

p,k

 

[Dan Evans]

Suppose one has a Web app where under certain circumstances a server
will take 10 seconds to come up with an answer.

The crummy library I am using times out at 5s by default. Here are the
options I see:

1. Increase the timeout

2. Don't ask the server to do so much all in one bite (I can readily
chop the one request up into smaller bits).

3. Ask the user if they want to wait after 5s.

#2 is feasible but a nuisance. Is #1 rude to the user, aka bad form for
well-behaved web apps?

Did I miss a #4?

I would increase the timeout myself but I'd also make sure that the
interface reflects what's happening. The most important thing here is
not how long the app takes to respond but how long it feels like it
takes to the user. (Not that the actual time isn't something to
minimize as well.)

When a user clicks a button that will make a request which may take a
while, if the script on the client deactivates the button and displays
an animated indicator that something is happening it will seem very
responsive. So even if it takes a while the user will not be upset
about waiting. You may have seen animated indicators on "ajax" sites,
you can also google for "ajax indicator" to see some examples. Also,
sometimes it makes sense to cover/deactivate something besides just
the button while the request takes place, such as the area in which
the content is going to appear.

If the UI takes 2 or 3 seconds to be responsive it can actually seem
worse to the user than if it takes 10 seconds to get the data but
responds immediately.

That being said, I would also concentrate on getting the time on the
server down to something more reasonable.

Depending on if it's appropriate in your case you might also consider
making the requests before the user clicks and then caching the
results. This wouldn't be as good of an idea if it's difficult to
predict which one of a wide variety of requests will be made.

Hope that helps.

Cheers,
Dan Evans

 

[Kenny]

I would increase the timeout myself but I'd also make sure that the
interface reflects what's happening. The most important thing here is
not how long the app takes to respond but how long it feels like it
takes to the user. (Not that the actual time isn't something to
minimize as well.)

When a user clicks a button that will make a request which may take a
while, if the script on the client deactivates the button and displays
an animated indicator that something is happening it will seem very
responsive. So even if it takes a while the user will not be upset
about waiting. You may have seen animated indicators on "ajax" sites,
you can also google for "ajax indicator" to see some examples. Also,
sometimes it makes sense to cover/deactivate something besides just
the button while the request takes place, such as the area in which
the content is going to appear.

If the UI takes 2 or 3 seconds to be responsive it can actually seem
worse to the user than if it takes 10 seconds to get the data but
responds immediately.

Yes, it is amazing what a difference that makes. In our case since the
slow task is loading all the rows in a grid I could just load two rows
at a time or something, both avoiding the timeout /and/ giving the user
the warm fuzzy of seeing something happening. But...

That being said, I would also concentrate on getting the time on the
server down to something more reasonable.

Absolutely. The server takes 300-600ms to decide just one row of
information... I can't wait to see what /that/ is doing wrong. Must be a
missing index: we have some huge in-memory tables it must be mapping
over sequentially.

Depending on if it's appropriate in your case you might also consider
making the requests before the user clicks and then caching the
results. This wouldn't be as good of an idea if it's difficult to
predict which one of a wide variety of requests will be made.

Right, they can point to any one of hundreds of suppliers and we have to
list the items that supplier provides. But we could kick off lookahead
on the items in case they go scrolling... well, the real cost of loading
a row is normally just a few msec, so I think I'll just see where we are
losing those two orders of magnitude.

Thx,

ken

 

[Jorge]

And no, I harrass you because you annoy me and propably 99% of the
readers of this group judging by the warm welcome your postings receive.

Not me. What annoys me are the posts along the lines of yours.

When/if you have nothing to say, don't say anything (i.e. don't post),
thanks.