gemini+stream://

[cage]

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 because
i 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 me
give you an example (sorry i have to talk about my work, i hope you do
not feel this annoying).

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

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

(At this time  i could not handle, for example,  an endless audio file
but  i consider  this  an issue  of  my  client not  an  issue in  the
protocol.)

At this moment (assuming no bug in  my code and that i have understood
the 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 to
enforce 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 this
to me! :)

Bye!
C.