Reopening: Stream status code

Hello all,

A stream status code has been mentioned on this list before, and I'd like to
bring it up again. Streams have begun appearing on Gemini, notably on
gemini://chat.mozz.us. But at the same time, responsible clients have been
adding timeouts for server responses. It is even part of the Egsam test, under
section 1.1: gemini://egsam.pitr.ca/1.1.gmi.

The best solution that I see, as I believe that streams can be very useful and
interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.

Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
spec from now on, but I hope he will see this as an important exception.

Thank you,
makeworld

On 18-Jul-2020 22:09, colecmac at protonmail.com wrote:
> A stream status code has been mentioned on this list before, and I'd like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have been
> adding timeouts for server responses. It is even part of the Egsam test, under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.
>
> The best solution that I see, as I believe that streams can be very useful and
> interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.
>
> Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
> spec from now on, but I hope he will see this as an important exception.
Hi makeworld and everyone

I would be against this - it would be a radical change from the existing 
spec - section 1.1 says that the server closes the connection. At 
present we have a simple model - client request-> server response and 
close. Would it be an optional status code that some clients accept and 
others reject (in which case it would seem to violate that you can just 
check the first digit of the status).

It would require a considerable change to the connection logic to some 
clients which wait for the content to be finished being delivered before 
rendering.

For my money if we are opening up these kinds of questions there would 
be others that should be considered. I'm on for a wider discussion about 
evolution of the spec, but not just for this matter on its own.

Best wishes

  - Luke

All good points, thanks. I think it would make sense for some clients
to reject this yeah, but that would break things as you mentioned. Hmm.

makeworld

On Sat, Jul 18, 2020 at 5:09 PM <colecmac at protonmail.com> wrote:
>
> Hello all,
>
> A stream status code has been mentioned on this list before, and I'd like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have been
> adding timeouts for server responses. It is even part of the Egsam test, under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.
>
> The best solution that I see, as I believe that streams can be very useful and
> interesting, is to add a SUCCESS AS STREAM status code. I propose status code 21.
>
> Thoughts? I know Solderpunk has said that there won't be non-trivial changes to
> spec from now on, but I hope he will see this as an important exception.
>
> Thank you,
> makeworld
>

Hi!

I really like the idea of streaming in gemini! I don't know if it will ever see
widespread adoption outside of a few tech demos, but it's fun to play around
with nonetheless. Here are some of my thoughts on adding a separate status
code.

First, I haven't yet heard a justification for why a client should ever force
the connection to timeout. Adding a short timeout on resolving the host and
establishing the connection, sure that makes sense to me. But why force close
the connection once it has already been established? With gemini's single
request/response model, there should be a person sitting in front of the
keyboard waiting for the page to load. Show them the transfer rate in
bytes/second and let *them* make an informed decision of when to give up based
on their own context. Doing anything else is taking away agency from the user,
and for what gain? If I want to sit in front of a loading screen for an hour
(and keepalive packets are still being sent) I should be allowed to.

The above paragraph doesn't apply to automated requests coming from tools like
gemini scrapers. Those will obviously still need some sort of global timeout on
all connections, regardless of whether they are marked as streaming or not. But
I would argue that that problem is better solved with something like robots.txt.

Second, I haven't yet heard a justification for why clients should be forbidden
from handling responses before they have finished downloading. This is more
fundamental than streaming as it is being discussed in this thread. If I
download a 300 MB mp3 file from your gemini capsule, I should be able to
start playing the audio before the whole thing has finished downloading.
Likewise for rendering images or large text files.

I would argue that "handling" a response also includes saving it to the
filesystem, so any gemini client that can stream a large response to a file
instead of holding the whole thing in memory is already doing this.

Third, I will suggest that the distinction between "streaming" and "non-
streaming" is totally meaningless. Hannu recently stood up an ansi art
mirror [0] which hosts small text files and puts a short time delay between
characters to emulate old modems. Is this streaming? The files have a finite
size and download fairly quickly. Even a naive gemini client could download
them, although it might appear slow. If there was no artificial delay, it
certainly wouldn't be considered streaming. But what if the delay was bumped up
to 30 seconds between characters? What if the delay was not deliberate, but
caused by a slow filesystem on the server? Going in the other direction, if my
server hosts a 1 TB image file it might as well be considered an infinite
stream for all practical purposes.

In summary, my feeling is that most of the features that we associate with
streaming are also relevant to all other gemini requests. If a client wants to
support streaming pages like gemini://chat.mozz.us, then they don't need a
status code to make that distinction. There might be some value in a separate
status code to inform dumb clients that they should not even attempt to load
the page. But there's no clear line to draw in the sand between what is
streaming and what isn't. I think this kind of context information is better off
in human-readable descriptions next to links.

- mozz

[0] https://portal.mozz.us/gemini/ansi.hrtk.in/

Well, the reason I added a timeout to deedum was because some servers 
don't close the connection, and the client was much easier to write if the 
connection terminated.

So, first the ability to tell the user that the server was unresponsive vs 
asking them to wait for things to stream-in seems important, otherwise how 
long are they supposed to wait? What if the server just hits an infinite loop?

Yet I question the reason behind keeping an open connection. The ability 
of a client to render progressive docs, images or video is seems 
orthogonal to a status code that says this connection will not close. Some 
of the streaming things out there seem very... application-y, and getting 
away from the app platform that is the web was a major motivator for me to 
invest in gemini. This feels like comet which was basically ajax which 
made everything terrible. Just my ptsd though.

On Sat Jul 18, 2020 at 11:09 PM CEST,  wrote:
> Hello all,
>
> A stream status code has been mentioned on this list before, and I'd
> like to
> bring it up again. Streams have begun appearing on Gemini, notably on
> gemini://chat.mozz.us. But at the same time, responsible clients have
> been
> adding timeouts for server responses. It is even part of the Egsam test,
> under
> section 1.1: gemini://egsam.pitr.ca/1.1.gmi.

Sorry I didn't chime in on this the first time it came up:  I meant to.
I like all the streaming experiments which have been floating around,
it's cool stuff.

My biggest objection (and I think it's a fatal one) to the idea of
having a 2x status code to convey that a stream is coming is that the
second digit of status codes is supposed to be ignorable without any
serious negative consequences and treating, say, 21 differently from 20
is supposed to be strictly optional on the part of client authors.  If
streamed content breaks clients which take advantage of that
optionality, that's a problem.

Even ignoring that, having separate 20 and 21 codes for "here comes a
non-stream" and "here comes a stream" doesn't make much sense, because
non-streams can be handled perfectly well using exactly the same code,
so the most concise implementation would be to have exactly the same
code handling two different status codes, which makes the different
statuses redundant.

This is mainly just an issue of what to do about timeouts, right?
If you don't have any timeout at all, streamed content works fine, but
buggy/overloaded servers hang the client, and that's bad.  If you have a
fixed timeout of 5 seconds, some streaming applications (like the chat
example mozz has done) break.

Does having clients use, say, a 5 second inital timeout after sending
the request, which gets bumped up to something a little higher after
successfully receiving a response header help a bit here?

Cheers,
Solderpunk

Having read all the responses, I think main reason I brought this up
is because of clients (mine and others) that attempt to download the
entire content before rendering it. It seems that this is a poor
strategy, and if I fix that, then stream issues will be solved. Might
be a good thing to add to an FAQ somewhere.

Thanks,
makeworld

On Sat, 18 Jul 2020 23:05:21 +0100
Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> I would be against this - it would be a radical change from the existing 
> spec - section 1.1 says that the server closes the connection. At 
> present we have a simple model - client request-> server response and 
> close. Would it be an optional status code that some clients accept and 
> others reject (in which case it would seem to violate that you can just 
> check the first digit of the status).

I agree that this is a radical change. I think other protocols largely
cover potential use cases for indefinite text/gemini responses, and
Gemini can by design concede such functionality to other software via
e.g. ircs/ssh URLs instead of creating an additional burden on Gemini
client implementations.

A quite opposite change I'd much rather see, however radical, is some
kind of required content length indicator in the header, but I'm also
willing to hear what use cases people are envisioning for streaming
responses. There has been talk about whether it can be done, and AFAIK
a sort of half-IRC to demonstrate that it indeed works in some clients
as a side effect of their design, but I haven't heard of a really
compelling use case yet.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/90f5
9c9b/attachment.sig>

Philip Linde <linde.philip at gmail.com> wrote:

> A quite opposite change I'd much rather see, however radical, is some
> kind of required content length indicator in the header,
>

Are you proposing adding content lenght to the MIME type? That has been
rejected every time the topic has come up and has led to the discussion of
alternative ways to communicate such meta data.

The point is to not have an extendable header.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/8f41
9cf3/attachment.htm>

On Fri, 31 Jul 2020 12:03:42 +0200
Katarina Eriksson <gmym at coopdot.com> wrote:
> Are you proposing adding content lenght to the MIME type? That has been
> rejected every time the topic has come up and has led to the discussion of
> alternative ways to communicate such meta data.

No, I'm suggesting in general a protocol-level way of communicating in
advance how many bytes will follow the header. I am not aware that MIME
types can be used for that purpose.

> The point is to not have an extendable header.

The header needn't be extensible to support this. It could be a
required part of the header (my original thinking, hence admitting that
this is quite a radical change) or it could be optional in the same way
that the MIME type is optional (which would not be nearly as useful and
probably would still break a fair amount of existing clients, but
would at least not require a change on servers).

The purpose would be to give clients some information that can serve as
a basis for timeout heuristics, when to close connections to misbehaving
servers and the means for a client to separate early close from
intentional end-of-document.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/f9fd
bbf3/attachment-0001.sig>

Please don't. That would complicate generated responses. The server would
have to hold the response until the whole thing was rendered just to count
the number of bytes. It's a lot simpler to write the data as it's ready,
which also avoids (potentially large) temporary memory allocations.

Paul

On Fri, Jul 31, 2020, 6:34 AM Philip Linde <linde.philip at gmail.com> wrote:

> On Fri, 31 Jul 2020 12:03:42 +0200
> Katarina Eriksson <gmym at coopdot.com> wrote:
> > Are you proposing adding content lenght to the MIME type? That has been
> > rejected every time the topic has come up and has led to the discussion
> of
> > alternative ways to communicate such meta data.
>
> No, I'm suggesting in general a protocol-level way of communicating in
> advance how many bytes will follow the header. I am not aware that MIME
> types can be used for that purpose.
>
> > The point is to not have an extendable header.
>
> The header needn't be extensible to support this. It could be a
> required part of the header (my original thinking, hence admitting that
> this is quite a radical change) or it could be optional in the same way
> that the MIME type is optional (which would not be nearly as useful and
> probably would still break a fair amount of existing clients, but
> would at least not require a change on servers).
>
> The purpose would be to give clients some information that can serve as
> a basis for timeout heuristics, when to close connections to misbehaving
> servers and the means for a client to separate early close from
> intentional end-of-document.
>
> --
> Philip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/3bd8
36d8/attachment.htm>

On Fri, 31 Jul 2020 07:01:10 -0400
Paul Boyd <boyd.paul2 at gmail.com> wrote:
> Please don't. That would complicate generated responses. The server would
> have to hold the response until the whole thing was rendered just to count
> the number of bytes. It's a lot simpler to write the data as it's ready,
> which also avoids (potentially large) temporary memory allocations.

That is true. There are approaches to dynamically generated responses
that avoid the need for preallocation, but they are indeed quite
complex compared to having e.g. a CGI script simply dump some data on
its standard output.

Usually, when I need to determine a buffer size in advance, I implement
a "dry run" of whatever fills the buffer that instead of writing
anything simply tallies up the number of bytes that *would* be written
and run that to determine the size of the buffer before a "real" run. A
similar approach can be used to determine content length for CGI
scripts.

It's a good point nonetheless.

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/7856
c218/attachment.sig>