Protocols (Was: HTTP)
John H. Robinson, IV
jhriv at ucsd.edu
Wed Dec 11 13:22:56 PST 2002
Nick Bastin wrote:
> What? We're talking about web apps here
okay - how about this - i know of a financial institution that has a
they give you X minutes (i think it is selectable between 5 and 60
minutes) to do something, otherwise i make you go away.
i believe it is reasonable to be able to start your banking application,
and perform your transaction, then stop w/in 10 minutes. or at least no
more than 10 minute ``uh, what was i doing?'' time.
that is what i mean.
> what does it have to do with ssh or FTP?
ssh and ftp both time out after inactivity. the socket is closed, and it
is no more. http/2.0 (as i supose it) can do that, too.
> HTTP closes the connection because the largest percentage of the time
> is going to be in idle anyhow, which would cause a timeout.
perhaps we see the world vastly differently.
i have to assume that you are likely to open a network application, and
let it sit idle for hours at a time, (such as a calendaring system). but
i see network applications open, used, then closed.
how would i design something that is meant to be open, and kept open,
idle for hours? probably something like cvs' pserver. reauthenticate at
each desired interaction. of course, the client would have to be nice
and keep some information client side, in RAM (like authorisation tokens,
i mean passwords or passphrases in this case). but typical web browsers
do not lend to this, other than server supplied cookies.
so we are back to the: web browsers as application interfaces _SUCK_.
too many limitations. too many problems. yeah, using HTTP and HTML is
nice because the managers like it, but that's about it.
and the next person who says ``but it is platform independent'' needs to
spend a week browsing all of their favourite applications with lynx.
then come to realise ``man, this sucks'' no netscape, no mozilla, no
msie, no opera.
some sites are _very_ lynx friendly. there are even good
shopping carts that are lynx friendly, and do not require
cookies. (can you say HTTP POST? i knew you could!) but they
are rare, and need to be cherished very highly.
these same people then need to spend some time with a real web
developer, and see the hoops that have to be jumped through to make an
application behave the same onthe varying GRAPHICAL browsers. forget
lynx, who cares? no one uses that anyway.
when you have control (Tk), then you don't have to worry anymore, do
> What you are saying is like suggesting that FTP keep the data connection
> open even after it's done transferring the file because you might want to
> send one again in the future.
why keep the data connection open? you already have the control open.
that is where your state lies. you could keep the timeout really low on
the data port, like say five seconds. load profiling with and without a
small timeout (assuming that the clients understood) would tell you if
it is of any help or not.
More information about the KPLUG-List