💾 Archived View for rawtext.club › ~sloum › geminilist › 001494.gmi captured on 2020-09-24 at 01:50:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Tadeusz Sosnierz tadeusz at sosnierz.com
Wed Jun 10 12:16:48 BST 2020
- - - - - - - - - - - - - - - - - - -
2020-06-10 12:36 GMT+02:00 Natalie Pendragon<natpen at natpen.net>:
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.
I feel the same way; sounds like no matter what you pick will become the"64 kilobytes" of tomorrow's jokes. And ultimately it doesn't allow theintroduction of a meaningful progress indicator. Is 100MBs a lot? Is it a long wait?I don't know, is the upstream server fast? Is my wifi having a good day?
The alternative is tricky to come up without making the response structure arbitraryand complex. Here's a take though: anything bigger than a megabyte or ten is realisticallynot going to be text, or anything text-like that can be displayed inline. I can think of images,videos, maybe PDFs or just a bunch of encrypted data in the form of whatever.I wonder if it'd make sense to have a status code that indicates“mimetype is basically meaningless, it's a big whatever,so I'll give you the content length instead“.
Client could then choose to receive a few more bytes and check a magic byte for somethingit recognizes – or just prompt the client saying “that's not exactly something we can display anyway,(how) do you want it saved?”
--tadzik