"Wide load" status code(s)?
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 this
either way but I'll share a couple of thoughts.
One place I previously used gopher was IP routed over VHF packet
radio. These links are 1200 baud simplex with an effective throughput
of some 80 B/s. I'm not saying gemini can or should care what weirdos
are doing with VHF radios, but it may one day find use in scenarios
where quantities much less then 1 MB matter. If you're using such a
slow link, you might have to waste quite a lot of time to realise that
you're getting an above-average amount of content, reducing the
effectiveness of a client-side threshold.
One way to offer more flexibility could be to use the second digit of
the "2n" response code as saying "this content >= 10^n bytes".
But I would raise no objections to maintaining the status quo, or to
adopting the three codes suggested here.
Cheers, Tom
More information about the Gemini
mailing list