November 10, 2020 7:49 AM, "Johann Galle" <johann.galle at protonmail.com> wrote: > Both of these proposals sound very much like introducing MIME type parameters > as geminis version of headers, which is something to be avoided if I read > the [FAQ] correctly. > >> Proposal: Cache duration > > This has been discussed at length in this mailing list and I personally do > not see a convincing case as to why this is necessary with typical small > gemini documents. > >> Proposal: Response body size > > There is a section in the FAQ specifically on why gemini does not have this: > > tl;dr: It's not sensible for the small gemini documents, for larger files > you should use something else, e.g. torrent, IPFS etc. > > - SNIP - > > [FAQ]: gemini://gemini.circumlunar.space/docs/faq.gmi I keep hearing this argument and I don't agree with it one bit. (I'm not necessarily disagreeing with *you*, Johann, just in general.) One design criterion of Gemini is generality. As the FAQ puts it: > But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above. It's *possible* to serve large files over Gemini. I can make a script that generates a large image (or I can just have a large image to serve). Therefore, you should be able to use Gemini to serve large files. The main draw I can see for a Content-Length header is being able to see if the whole file comes across the wire. The ability to resume an interrupted download need not exist; just retry the request if all of the content doesn't get across. That being said, I am wary of making it even a SHOULD. If the file needs it (i.e; it's a big file that probably could get interrupted mid-download), then go ahead, but those of us who don't care about Content-Length or Cache duration shouldn't feel "pressured" to do it. Just my two cents, Robert "khuxkm" Miles (I should really set up an identity in my email client so my name shows up on the mailing list archive next to my email)
---
Previous in thread (5 of 16): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)