💾 Archived View for rawtext.club › ~sloum › geminilist › 001487.gmi captured on 2020-10-31 at 02:19:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
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 doa lot more for users in resource-limited environments, and in additionto the explicit austerity in the protocol itself, this is another wayto 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 allsituations well - adding three of them like you brought up at the endimproves the situation, but nevertheless still feels like a magicnumber solution. And depending on how future-proof you want these$THRESHOLDs to be, no matter how good the magic numbers are today, asyears pass and internet access/quality across the world changes, forbetter or worse, the magic numbers will become more and more out ofdate.
The only way I see to make it not a magic number is to allow clientsto 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 ideaB) I don't love the designC) I worry there may be no better design
And I would support speccing this if no better design arrives, becauseit is a meaningful issue to solve!
Nat