Reopening: Stream status code

[Solderpunk]

On Sat Jul 18, 2020 at 11:09 PM CEST,  wrote:
> Hello all,
>
> A stream status code has been mentioned on this list before, and I'd
> like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have
> been
> adding timeouts for server responses. It is even part of the Egsam test,
> under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.

Sorry I didn't chime in on this the first time it came up:  I meant to.
I like all the streaming experiments which have been floating around,
it's cool stuff.

My biggest objection (and I think it's a fatal one) to the idea of
having a 2x status code to convey that a stream is coming is that the
second digit of status codes is supposed to be ignorable without any
serious negative consequences and treating, say, 21 differently from 20
is supposed to be strictly optional on the part of client authors.  If
streamed content breaks clients which take advantage of that
optionality, that's a problem.

Even ignoring that, having separate 20 and 21 codes for "here comes a
non-stream" and "here comes a stream" doesn't make much sense, because
non-streams can be handled perfectly well using exactly the same code,
so the most concise implementation would be to have exactly the same
code handling two different status codes, which makes the different
statuses redundant.

This is mainly just an issue of what to do about timeouts, right?
If you don't have any timeout at all, streamed content works fine, but
buggy/overloaded servers hang the client, and that's bad.  If you have a
fixed timeout of 5 seconds, some streaming applications (like the chat
example mozz has done) break.

Does having clients use, say, a 5 second inital timeout after sending
the request, which gets bumped up to something a little higher after
successfully receiving a response header help a bit here?

Cheers,
Solderpunk