💾 Archived View for gemi.dev › gemini-mailing-list › 000325.gmi captured on 2024-05-12 at 16:03:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Several of us had a fruitful discussion about gemini streaming over in the IRC channel tonight. For those of you who don't IRC, the full logs of the channel are available from my weechat logs, updated nightly at 0000UTC: gemini://tilde.black:1965/users/fox/irc/log.txt I strongly believe there's tangible value in having streaming support for the text/gemini mime-type. We have the lovely chatroom proof-of-concept out there already, and a few minutes of brainstorming came up with speech-to-text broadcast radio using Watson's speech-to-text engine. The cool ideas already floating around solderpunk's head in his gemlog about Gemini applications haven't been forgotten either. There's an untapped goldmine here. That being said, the protocol has a very simple flow defined currently wherein a client makes a request, the server responds, ends the connection, then the client processes it. Changing that fundamental behavior to support streaming is not an insignificant thing to ask of client authors, and some will have no desire to do so at all. We've talked in the past about possibly serving a different response code to signify to a client that this resource wants to stream, but that was countered with valid reasoning. Tonight I tried making the argument for a text/gemini+stream mime-type instead. Lukee challenged that, and ultimately I have to admit it leaves out one important aspect of serving streaming content: the user should be aware that the resource intends to stream. Whether we serve a mime-type, response code, or somehow talk solderpunk into content-length information, none of these will be available as information to the user before they select a link. The only way to make it clear to a user that a stream is intended for a link, then, is a protocol indicator. gemini+stream:// That's my recommendation for several reasons: 1. We're not changing much in the default gemini protocol. What we are indicating is that the client should not wait for a connection close to begin processing/displaying content. We are also signaling to the user that this resource intends to stream. Everything else about the connection remains otherwise default gemini behavior. Giving it a new protocol name would suggest there's more differences here and possibly open a doorway for other scope creep. 2. By keeping gemini in the protocol name still this tightly couples it with Gemini. This isn't something that is designed to go off and live on its own or be in any way confused as its own system. There was discussion about Titan when this idea came up. I personally still prefer gemini+write:// for that extension for the same reasons as above, but as Alex is doing literally all the work on it himself, I defer to him. 3. It's not gemini:// and therefore it is inherently not a part of the gemini core requirements for clients. I think streaming is fascinating, but I don't want to suggest that it be a requirement to support it like we have for the text/gemini mime-type. It represents a different way of consuming data and presenting it that would turn a weekend project into a two weekend project. Having a supplemental protocol fits better. 4. (sort of related to #3) Having "something" as a standard avoids the vagueness we have right now where people will try whatever makes sense to them in the moment. They'll get it working on their personal client and that's the extent of it. With something defined we all have a common target. 5. It doesn't inherently limit itself to the text/gemini mime-type since the streaming behavior is indicated by the protocol itself. It could also stream plain text, for instance, or even an mp3. The individual mime would have to make sense in a streaming context, but the door is technically 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 believe this answers all the concerns we've had voiced before about streaming. It allows for an optional extension of gemini that explicitly allows for a persistent streaming connection without breaking anything natural or inherent in the core protocol. But please chime in and correct me if I've missed something important. This turned into quite the post! Yeesh
On 15-Aug-2020 00:39, James Tomasino wrote: > Several of us had a fruitful discussion about gemini streaming over in the IRC channel tonight. For those of you who don't IRC, the full logs of the channel are available from my weechat logs, updated nightly at 0000UTC: > > gemini://tilde.black:1965/users/fox/irc/log.txt Yes fruitful and robust in a friendly way - I enjoyed it. Thanks for your write up which is a good and fair summary of some of the key points. > I strongly believe there's tangible value in having streaming support for the text/gemini mime-type. We have the lovely chatroom proof-of-concept out there already, and a few minutes of brainstorming came up with speech-to-text broadcast radio using Watson's speech-to-text engine. The cool ideas already floating around solderpunk's head in his gemlog about Gemini applications haven't been forgotten either. There's an untapped goldmine here. Personally I don't have a horse in the streaming race in terms of needing it. I think perhaps a good degree of the use cases could be captured by client based polling, but not all. I think things like live streaming of audio over gemini and similar binary streaming is way out of scope and there are better clients and protocols for that. Text streaming maybe, but it is a bit niche IMO and there are other options like IRC. > That being said, the protocol has a very simple flow defined currently wherein a client makes a request, the server responds, ends the connection, then the client processes it. Changing that fundamental behavior to support streaming is not an insignificant thing to ask of client authors, and some will have no desire to do so at all. For me one of the key benefits and attractions of the gemini protocol is its simplicity, which eases diverse implementation. Client request->server response and close. You know to expect a fixed block of content from the server that is the payload. Mixing in a stream mode with the standard document mode does muddy the waters somewhat in terms of what expectations a client will have of the server behaviour, but as you way perhaps the main challenge is that client behaviour needs to be different in each mode. For example, if streaming text, it might be better to use a fixed window size (10 lines or 1 line even). And clients need to know the difference between a server that is slow/timed out vs one that might push you some more content later. > We've talked in the past about possibly serving a different response code to signify to a client that this resource wants to stream, but that was countered with valid reasoning. Tonight I tried making the argument for a text/gemini+stream mime-type instead. Lukee challenged that, and ultimately I have to admit it leaves out one important aspect of serving streaming content: the user should be aware that the resource intends to stream. Its not just that end users can benefit from advance knowledge of the upcoming interaction, but it is clients too that can take appropriate action, for example to switch rendering mode, to not abandon a long timed stream that might otherwise seem to be broken, to offer a choice to the user, or decide not to handle it further. As we know in gemini there are no other headers we can use to indicate content length or what modes the client can accept. > Whether we serve a mime-type, response code, or somehow talk solderpunk into content-length information, none of these will be available as information to the user before they select a link. The only way to make it clear to a user that a stream is intended for a link, then, is a protocol indicator. > > gemini+stream:// > > That's my recommendation for several reasons: > > <snip> > > I believe this answers all the concerns we've had voiced before about streaming. It allows for an optional extension of gemini that explicitly allows for a persistent streaming connection without breaking anything natural or inherent in the core protocol. But please chime in and correct me if I've missed something important. I think this is a nice solution, in that it clearly indicates the expectation the client should have about server behaviour and can act accordingly. Similarly as users click/activate links in their clients they will get an indication of a shift in server mode. I suspect there may still be some corner cases of a text streaming mode that might need to be thought through. For example the streaming display window from a UI point of view. Is this always in the gift of the client or is it something the server/app author would want to determine? I can think of both modes being appropriate for different use cases. One mode might be a news ticker, another a sort of twitter feed (shudder), or a third, to send a "virtual screen" of a formatted status picture. Similarly for other kinds of binary streaming (if you really want to go down that road), are there other sorts of metadata necessary? I don't know I'm not a specialist in this area at all. But generally I think its a good solution to give it another protocol name. Best wishes - Luke
On Fri, Aug 14, 2020 at 11:39:20PM +0000, James Tomasino wrote: Hi! 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. > 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. Bye! C.
Gemini currently allows a fetch-then-process model, while a URL that refers to a streaming resource forces me to: - a) intercept the response and make a decision on how to proceed, or b) wait for a timeout There's plenty of tech for which implementing the above is trivial, but it's currently not mandatory. If my client pipes the output to another process, there's no reason for either process *not* to wait till the server closes the connection - I currently have every reason to expect that the server is sending me data for any Gemini request. Knowing in advance that a server will not close a connection means that steaming works, existing clients don't hang or break, new clients aren't forced to add extra complexity, and unnecessary requests can be avoided entirely. This is just my take, anyway! Kevin On Sat, 15 Aug 2020 at 11:47, cage <cage-dev at twistfold.it> wrote: > > On Fri, Aug 14, 2020 at 11:39:20PM +0000, James Tomasino wrote: > > Hi! > > 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. > > > 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. > > Bye! > C.
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.
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.
On Sat, Aug 15, 2020 at 05:00:18PM +0100, Kevin Sangeelee wrote: Hi Kevin! Thank you for your reply, Hope you do not mind that, to avoid repeating the same concepts, i wrote a single message that try to answer to you and easeout at the same time. Bye! C.
On 8/15/20 6:41 PM, cage wrote:
> 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).
This was the original point I missed as well when I first started talking
about streaming in Gemini. According to the specification section 1.1,
here's the transaction summary:
C: Opens connection
S: Accepts connection
C/S: Complete TLS handshake (see section 4)
C: Validates server certificate (see 4.2)
C: Sends request (one CRLF terminated line) (see section 2)
S: Sends response header (one CRLF terminated line), closes connection
under non-success conditions (see 3.1 and 3.2)
S: Sends response body (text or binary data) (see 3.3)
S: Closes connection
C: Handles response (see 3.4)
Notice that final "Closes connection" before "Handles response". If that
were reversed then the protocol would effectively assume everything was a
stream and everyone's clients would be built in the manner you've been
working toward. Since it's explicit that the connection closes first in
the spec it's understandable that client authors built clients the way they have.
Your technique of treating everything as a stream may "just work" for
gemini:// and gemini+stream:// both, honestly. Time will tell!
On Sat, Aug 15, 2020 at 08:41:24PM +0200, cage wrote: > > - 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?" @tomasino's reply reflects my understanding, so yes, I think so. > 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? Right!
On Sat, Aug 15, 2020 at 07:59:18PM +0000, James Tomasino wrote: Hi!! > On 8/15/20 6:41 PM, cage wrote: > > 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). > This was the original point I missed as well when I first started > talking about streaming in Gemini. According to the specification > section 1.1, here's the transaction summary: [...] > Notice that final "Closes connection" before "Handles response". If > that were reversed then the protocol would effectively assume > everything was a stream and everyone's clients would be built in the > manner you've been working toward. Since it's explicit that the > connection closes first in the spec it's understandable that client > authors built clients the way they have. Thank you very much! Now i understand what i was missing and everything is more clear! Now i think it is better that i think a bit about all the information in this thread. > Your technique of treating everything as a stream may "just work" > for gemini:// and gemini+stream:// both, honestly. Time will tell! And, in the meanwhile, i have a lot of bugs to fix! :)) Bye! C.
On Sat, Aug 15, 2020 at 04:28:50PM -0400, easeout at tilde.team wrote: > > 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? > > Right! Thank you for help me to understand! Bye! C.
> gemini+stream:// I've said this on IRC, but just so it gets seen in the mailing list too... Usage of a + in URI schemes is usually for when a protocol is being sent over another protocol. For example svn+ssh:// (svn protocol over an ssh connection) [1] [2] I think it should be gemini-stream:// [1] https://www.iana.org/assignments/uri-schemes/prov/svn [2] https://github.com/whatwg/url/issues/230 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200817/a3d1 aa20/attachment.sig>
Heya! > [Encoding the "is stream" information in the URL scheme] I really love this idea! It's easy to recognize for the user and the tools. Clients can just not support `gemini-stream://` and do their default behaviour for `gemini://`. I like it! Regards - xq
---
Previous Thread: Installing CAPCOM on FreeBSD 12.1 (need gusmobile)