gemini+stream://

[easeout at tilde.team]

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 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.

> >  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.