-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
@clseibold Yes, but not making this distinction means a UX problem: the user needs to know if the client is waiting for the end of the file (through a progress bar?) or filling a buffer before it can show something (a spinner?) or the buffer is empty because download has stalled (a spinner?) or everything is OK but the client is still receiving more data while displaying something. The client can delegate the work of displaying a file to some other component, be it a separate application or not, but it can be confusing for the user if the download part and the display part don't communicate so the client can't explain what's going on.
2023-12-04 · 6 months ago
Rosy Crow runs into a problem similar to what @skyjake described. It's using the native Android WebView to render page contents, so all incoming Gemtext must first be transformed into a valid HTML document and sent to the embedded browser. Since HTML cannot be appended-to in a simple fashion, this means that the whole document has to be re-generated.
One workable solution in this case would be to add some javascript to manipulate the DOM as new content arrives. I will likely end up doing this at soem point, but it sounds like it will be a PITA to test.
Along the lines of what @dimkr was mentioning: while the matter of a malicious/slow server seems like an irrelevant corner-case; it's one of those problems that throws a wrench into the whole concept of just waiting for the server to close the connection. It also adds significant complexity to the UI/UX side of things:
If a host is drip-feeding me bytes:
How long do I wait until I ask the user whether they want to cancel the request?
Will it get annoying if I do that for every slow response, even on a site with lots of streaming?
What if the user indicated they want to stream, but the server then *actually* fails for some other reason and never kills the connection?
@Addison you can't distinguish between a troll server that sends the document x bytes at a time to annoy you, and a server that "streams" the response in chunks but sometimes network latency is higher or reliability is lower. And this is also true for streaming of audio and video, not just gemtext. The only "solution" is having socket timeouts (for sending and receiving) so the transfer fails if nothing is received (or acknowledged) for some time, but also per-session timeout (so download fails after a while if the server keeps sending more data but the file is really big or endless).
@clseibold Maybe TCP keepalives, but a client may close a session after some deadline regardless of last I/O time, or terminate sessions based on time since last I/O (last packet carrying more data to display) instead of time since the last packet (including keepalive packets). Gemini is not really designed for streaming, it can be done but you need to make assumptions about the client and that means a capsule marked 'works best with x', like old sites built with IE in mind.
@clseibold I see things differently, I think that supporting a MIME type is one thing, but assumptions about client behavior is another. For example, some capsules have links that align nicely in Lagrange, and Station expects a client certificate for / although it's /join that returns 60 (Lagrange defaults to certificates for /, so it "just works"). In gplaces, I had to mimic Lagrange in some corner cases - for example, only warn, not show an error, if a capsule doesn't send close_notify like the spec says. I don't like capsules that work better with a specific client, or only with a specific client.
Yes you are correct about the history @clseibold.
This reminds me I should use the "/?register" solution myself in Bubble, because having an actual "Create Account" UI action beats the current "just activate a certificate but please only at the root".
@clseibold @skyjake This history shows how much "wiggle room" the spec has, allowing clients to behave very differently from each other, until clients and servers achieve some status quo not mandated by the spec. I know that my client (and probably many others) doesn't support "chat" because it previews the document during download but shows the prompt that allows you to navigate to a link only when transfer is finished.
I saw a comment by @clseibold earlier (hope I spelled that right) talking about streaming audio capabilities in mobile Gemini clients. I can't seem to find the post anymore, but it got me thinking about whether Opal (the client library that Rosy Crow uses to do it's Gemini stuff) can support that. [https link] Currently it does not support that, because the entire response is read all at once into a buffer. Thinking about this a while, I of course arrived at the classic conclusion that...
-- Response ended
-- Page fetched on Sun Jun 2 15:06:02 2024