💾 Archived View for rawtext.club › ~sloum › geminilist › 006236.gmi captured on 2023-11-14 at 09:31:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Ecmel Berk Canlıer me at ecmelberk.com
Mon Mar 29 05:17:31 BST 2021
- - - - - - - - - - - - - - - - - - -
On 3/28/21 11:07 PM, almaember wrote:
or how much time it's going to take to download, or if it's even going
to end at all.
As far as I'm aware no client has solved this. If TLS close_notify gets standardized we might get a "connection failed" state, but other than that you won't be able to know how long the content is and whether you successfully downloaded it or not.
My ideas as of right now:
- Have a big buffer and store everything in it until the connection is
closed. The connection would be terminated if:
- the connection closes
- the server didn't send anything for X seconds
If I know which client you use I can just send a huge file over and possibly overflow your buffer. And it needs to be BIG. I'm aware of at least one capsule serving ~70MB files. (gemini://konpeito.media)
- Buffer by line and don't close the connection unless the user
terminates it (by pressing the stop key or by loading another
capsule). Compatible with long polling.
This is what I do on Moonlander. Not by line, as binary data can be sent over Gemini, but in 1029 byte chunks (exactly the max length of one Gemini header. Saves me code in trying to split that too)
I send each chunk into a separate "renderer" for the given file type, which in text's case decodes it into the given encoding (default UTF-8) and sends it over to the text/gemini parser which then does the line splitting and parsing there. (And in other cases it will just save the bytes directly to a file)
It's a bit more work, but I have successfully downloaded a few of those 70MB files with this approach, so I'd say it's pretty robust.