💾 Archived View for rawtext.club › ~sloum › geminilist › 002418.gmi captured on 2020-11-07 at 02:53:41. Gemini links have been rewritten to link to archived content

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

gemini+stream://

cage cage-dev at twistfold.it

Sat Aug 15 19:41:24 BST 2020

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

On Sat, Aug 15, 2020 at 01:25:37PM -0400, easeout at tilde.team wrote:

Hi!

Thank you for your reply!

With this message i try to give an answer both to you an Kevin becausei feel my answer try to address the arguments raised by both of you.

On Sat, Aug 15, 2020 at 12:47:22PM +0200, cage wrote:

Honestly i fail to understand why a new scheme is needed here. The

protocol already supports stream as discussed in a previous messages

and i do no see a lott of advantages for using a different scheme

except (as you wrote) to signal to the user that the content will not

end.

Probably i am missing something, please help me to understand.

In our IRC discussion, we raised some user-facing guarantees of Gemini:

- You know that when you open a link, you're just getting that one file,

not an implicit bundle of child requests

- You know the connection will not remain open after you have begun to

see its content

OK, my honest question is now is: "is the last point true?". Let megive you an example (sorry i have to talk about my work, i hope you donot feel this annoying).

When i started my client i assumed all the content was non streamedand then, when i discovered it was not i felt very depressed becausemy code would be useless, then reading a previous message in thismailing list I started to assume every content got from server was astream. And started to code following this assumption.

Now, the code is crude and not complete but it works quite nice forendless flow of gemini formatted lines (so you see the contents of agemini file while the connection is still open) but also fordownloading a single file, so there is no need for different code forstreamed contents and non streamed contents.

(At this time i could not handle, for example, an endless audio filebut i consider this an issue of my client not an issue in theprotocol.)

At this moment (assuming no bug in my code and that i have understoodthe proposal correctly, two generous assumptions to be honest! :-D)all i need to support 'gemini+stream://' is just to treat it like'gemini://'.

As users, these guarantees feel good to us.

As an user too i agree! :)

And we have confidence in

these guarantees whenever we see a gemini:// link. So we would like to

keep that user confidence high. For that reason, we like the idea of

leaving the gemini:// scheme for content you download and then consume,

and a separate scheme for content you consume while the connaection

remains open.

OK i think i kind to understand the point, so what you propose it toenforce the second "guarantee" of your list for 'gemini://' scheme,and leave the "live" (sorry i can not find a better word)connections to the 'gemini+stream://' right?

6. It is still a single client-initiated request happening in the

foreground. We aren't creating background threads of who-know-what

running services. We're getting an ongoing document in real-time,

that's all.

I do not think this is entirely true if you want to update/keep alive

the UI of the client while the content is flowing from the

server. Some kind of concurrent works enter in the equation, i think.

I think the "foreground" versus "background" concept was really more

about what the user is made aware of. In that sense, a "background"

operation would be one that happens without the user's knowledge. We

like the idea that in Gemini, even if streamed, you don't stream

anything you're not aware of. If a second process or thread did the

work, but the user can see that happening, that's no problem.

So I was entirely missing the point here! Thank you for clarifying thisto me! :)

Bye!C.