💾 Archived View for rawtext.club › ~sloum › geminilist › 007688.gmi captured on 2024-02-05 at 10:30:04. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Streaming responses

Krixano krixano at protonmail.com

Mon Dec 13 20:23:33 GMT 2021

- - - - - - - - - - - - - - - - - - -

He was against the idea of a request, but was for the idea of allowing streams

To make sure I'm clear, I meant to type "He was against the idea of a request status code, but was for the idea of allowing streams"

Christian Seibold

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, December 13th, 2021 at 2:12 PM, Krixano <krixano at protonmail.com> wrote:

Philip Linde, It turns out you were already involved in this very discussion on the mailing list where Solderpunk had brought up the idea of Stream requests on July 14th, 2020 (subject title: "Re: Reopening: Stream status code"). He was against the idea of a request, but was for the idea of allowing streams. You're trying to make this seem more complicated than it really is when we have very simple handling of "streams" happening for a few clients out in the wild. The solution is that you can start displaying the content/data as it comes in (which is actually simple for gemtext, since it's line-based). In fact, the close_notify tells the client when a connection has actually finished. And then if you are not satisfied with that, then you can add a timeout, which servers should be doing anyways even if they weren't doing "streaming".

Solderpunk has made it sufficiently clear that clients can handle responses before the close_notify (and if I'm wrong, it's important that he corrects me), and this is for several reasons, one being that it's a better user experience with a very low tradeoff. The primary example of "streaming" (which is literally just handling data as it comes in) was Text Streaming. Things like mbays' games at gemini://gemini.thegonz.net/sggs/)

Next, about the specification. Nowhere does it state in the specification that steps cannot overlap. Again, you're using an overly-linear interpretation of that outline of the requests. Remember, the spec is not finished. It is important, however, I'm certainly not against things being more explicit in the spec. In fact, I think they should be.

Christian Seibold