💾 Archived View for rawtext.club › ~sloum › geminilist › 001496.gmi captured on 2020-09-24 at 01:50:46. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Thomas Karpiniec tkarpiniec at icloud.com
Wed Jun 10 13:16:03 BST 2020
- - - - - - - - - - - - - - - - - - -
On Wed, Jun 10, 2020 at 07:32:16AM +0000, solderpunk wrote:
Naturally, deciding to do this will lead immediately to a weeks-long
heated debate on what the appropriate value of $THRESHOLD should be. We
*could* wade into those waters, but I'll just also throw out that we
could use 21, 22 and 23 to indicate payloads exceeding 1MiB, 10MiB or
100MiB respectively and leave it at that. Clients targetting
resource-limited environments could let their users configure their own
threshold for early termination of downloads.
That's the real question isn't it? I don't feel strongly about thiseither way but I'll share a couple of thoughts.
One place I previously used gopher was IP routed over VHF packetradio. These links are 1200 baud simplex with an effective throughputof some 80 B/s. I'm not saying gemini can or should care what weirdosare doing with VHF radios, but it may one day find use in scenarioswhere quantities much less then 1 MB matter. If you're using such aslow link, you might have to waste quite a lot of time to realise thatyou're getting an above-average amount of content, reducing theeffectiveness of a client-side threshold.
One way to offer more flexibility could be to use the second digit ofthe "2n" response code as saying "this content
= 10^n bytes".
But I would raise no objections to maintaining the status quo, or toadopting the three codes suggested here.
Cheers, Tom