💾 Archived View for rawtext.club › ~sloum › geminilist › 007685.gmi captured on 2023-11-14 at 08:24:44. Gemini links have been rewritten to link to archived content

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

Streaming responses

Krixano krixano at protonmail.com

Mon Dec 13 20:12:04 GMT 2021

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

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

Sent with ProtonMail Secure Email.

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

On Monday, December 13th, 2021 at 1:00 PM, Philip Linde <linde.philip at gmail.com> wrote:

On Mon, 13 Dec 2021 10:48:33 +0100

Omar Polo op at omarpolo.com wrote:

(No, the outline of the transaction in 1.1 is not a formal description

of what each party should do, it's just an outline.)

Says who? It's part of the specification. There is nothing in the

specification itself that qualifies it as an informal hint. Given that

it's the only part of the specification that describes a complete

transaction, I take it to be clearly specified that the client handles

a response after the server closes the connection. Meanwhile, there's

nothing in the specification that remotely indicates that a client

should render content while the server is streaming it.

On the contrary, there's a post by solderpunk himself where he describes

exactly that:

gemini://gemini.circumlunar.space/users/solderpunk/gemlog/a-vision-for-gemini-applications.gmi

This perfectly exemplifies my point that it's easier to read a

specification than to go spelunking through gemlog posts to learn what

set of features I am currently expected to implement as a Gemini

implementor. What's extra funny is that you dismiss my references to

the specification as an informal part of it (with absolutely no basis)

and at the same time you refer to a gemlog where that pretty much only

documents that Solderpunk thought the idea was cool at some point.

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

Philip