"Wide load" status code(s)?
Natalie Pendragon
natpen at natpen.net
Wed Jun 10 11:36:05 BST 2020
I like the spirit of this idea a lot - Gemini has an opportunity to do
a lot more for users in resource-limited environments, and in addition
to the explicit austerity in the protocol itself, this is another way
to proactively respect users' resources and time.
What I feel less excited about is the specification of a hard-coded
$THRESHOLD. It feels like a magic number that's not going to fit all
situations well - adding three of them like you brought up at the end
improves the situation, but nevertheless still feels like a magic
number solution. And depending on how future-proof you want these
$THRESHOLDs to be, no matter how good the magic numbers are today, as
years pass and internet access/quality across the world changes, for
better or worse, the magic numbers will become more and more out of
date.
The only way I see to make it not a magic number is to allow clients
to specify a $THRESHOLD as part of their request - that, however,
feels like too big of a change to introduce to the Request structure
(even if we could make it gracefully degrade).
So, my conclusions are:
A) I love the idea
B) I don't love the design
C) I worry there may be no better design
And I would support speccing this if no better design arrives, because
it is a meaningful issue to solve!
Nat
More information about the Gemini
mailing list