💾 Archived View for rawtext.club › ~sloum › geminilist › 002269.gmi captured on 2020-09-24 at 03:14:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Solderpunk solderpunk at posteo.net
Sun Jul 19 15:09:24 BST 2020
- - - - - - - - - - - - - - - - - - -
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 ofhaving a 2x status code to convey that a stream is coming is that thesecond digit of status codes is supposed to be ignorable without anyserious negative consequences and treating, say, 21 differently from 20is supposed to be strictly optional on the part of client authors. Ifstreamed content breaks clients which take advantage of thatoptionality, that's a problem.
Even ignoring that, having separate 20 and 21 codes for "here comes anon-stream" and "here comes a stream" doesn't make much sense, becausenon-streams can be handled perfectly well using exactly the same code,so the most concise implementation would be to have exactly the samecode handling two different status codes, which makes the differentstatuses 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, butbuggy/overloaded servers hang the client, and that's bad. If you have afixed timeout of 5 seconds, some streaming applications (like the chatexample mozz has done) break.
Does having clients use, say, a 5 second inital timeout after sendingthe request, which gets bumped up to something a little higher aftersuccessfully receiving a response header help a bit here?
Cheers,Solderpunk