💾 Archived View for gemi.dev › gemini-mailing-list › 000306.gmi captured on 2024-03-21 at 17:20:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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>
---