💾 Archived View for rawtext.club › ~sloum › geminilist › 001486.gmi captured on 2020-10-31 at 02:18:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Wed Jun 10 08:32:16 BST 2020
- - - - - - - - - - - - - - - - - - -
Hey all,
Just throwing out a quick idea I had last night while trying to sleep,to see how people feel about it. It's simple and easily ignorable and Ithink it's kind of neat.
It's been a small pain point for some people for a while now that thereis no way for a Gemini client to know how large a file it's downloadingis without simply downloading the whole thing. This is inconvenientfrom a UI perspective, as there is no way to display a progress bar, andsimple clients like AV-98 which simply download a complete file and thenpass it off to a handler program appear to "freeze" on large downloadswith no clear indication that anything is happening. This is a muchbigger problem for people on limited machines (e.g. low memory disklesssystems are perfectly viable for reading text/gemini content anddisplaying small images but not for downloading large binaries, but theycan't gracefully opt out of the big stuff and are forced to simplyterminate the connection once a threshold amount of content has beendownloaded, and then wastefully discard that partial content) orinternet connections (e.g. people at sea using satellite data planswhich are billed per megabyte).
People usually want to address this by having the server somehow declarethe file size upfront in the header, as per HTTP's "Content-Length", butI've resisted that tooth and nail because there's no sensible way to doit which doesn't turn the response header into an infinitely extensiblething which people can tack their own variables onto, leaving us nobetter off than HTTP (so, please, no more ideas on this front)...
I was very happy to realise that a lot of these problems can be solved,or at least ameliorated, in a very simple way with an additional 2xstatus code. Since I plan to deprecate the current 21 code for ending atransient certificate session, we could reuse 21 to mean "SUCCESS, aresponse body follows, and it's larger than $THRESHOLD MiB" (note I amproposing no change to the existing code 20 - 20 does NOT mean "what'scoming in less than $THRESHOLD"). Simple clients could simply treat 21as 20 and be in exactly the situation they are in now, so the gracefuldegredation of status codes to their x0 form works nicely here. Bute.g. AV-98 could print "Downloading large file, please wait..." uponreceving a 21, and then proceed as usual. This is a very low effortclient change, but it solves the problem of people thinking somethinghas gone wrong when they unknowingly start a large download. Moreimportantly, users in resource-limited environments could use clientswhich simply terminate the connection immediately on seeing a headerstarting with 21, providing a quick and low-waste "opt out" of largecontent.
On the server side, again, a dirt simple server could just always serveup 20 without actually breaking anything. I realise that knowingwhether to use 20 or 21 for dynamically generated content may not bestraightforward - no problem, it is *always* valid to just send 20 whenin doubt. 21 is nothing more than a helpful hint to clients who mightneed it. It doesn't need to be 100% reliable to still have value.
This feels like a good idea to me. It's totally optional and very easyto handle on both the client and server sides, and I feel like beingfriendly to small/slow computers and slow/intermittent networkconnections is a good fit with the overall "vibe" of Gemini, provideddoing so does not conflict with overall simplicity.
Naturally, deciding to do this will lead immediately to a weeks-longheated debate on what the appropriate value of $THRESHOLD should be. We*could* wade into those waters, but I'll just also throw out that wecould use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or100MiB respectively and leave it at that. Clients targettingresource-limited environments could let their users configure their ownthreshold for early termination of downloads.
Cheers,Solderpunk