💾 Archived View for rawtext.club › ~sloum › geminilist › 002257.gmi captured on 2020-10-31 at 14:25:42. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sat Jul 18 23:05:21 BST 2020
- - - - - - - - - - - - - - - - - - -
On 18-Jul-2020 22:09, colecmac at protonmail.com wrote:
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.
The best solution that I see, as I believe that streams can be very useful and
interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.
Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
spec from now on, but I hope he will see this as an important exception.Hi makeworld and everyone
I would be against this - it would be a radical change from the existing spec - section 1.1 says that the server closes the connection. At present we have a simple model - client request-
server response and close. Would it be an optional status code that some clients accept and others reject (in which case it would seem to violate that you can just check the first digit of the status).
It would require a considerable change to the connection logic to some clients which wait for the content to be finished being delivered before rendering.
For my money if we are opening up these kinds of questions there would be others that should be considered. I'm on for a wider discussion about evolution of the spec, but not just for this matter on its own.
Best wishes
- Luke