💾 Archived View for rawtext.club › ~sloum › geminilist › 002413.gmi captured on 2020-11-07 at 02:53:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
easeout at tilde.team easeout at tilde.team
Sat Aug 15 18:25:37 BST 2020
- - - - - - - - - - - - - - - - - - -
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
As users, these guarantees feel good to us. And we have confidence inthese guarantees whenever we see a gemini:// link. So we would like tokeep that user confidence high. For that reason, we like the idea ofleaving the gemini:// scheme for content you download and then consume,and a separate scheme for content you consume while the connaectionremains open.
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 moreabout what the user is made aware of. In that sense, a "background"operation would be one that happens without the user's knowledge. Welike the idea that in Gemini, even if streamed, you don't streamanything you're not aware of. If a second process or thread did thework, but the user can see that happening, that's no problem.