On Wed, Mar 10, 2021, at 1:51 AM, Bradley D. Thornton wrote: > The problem with compression however, is that it has been stated several > times that Gemini is intended (expected, rather) to deliver mostly small > files, but not so ubiquitously so in my case. i.e., I've been a SCO > partner for many many years and I'm one of the only places I know of on > the net where you can freely download ISOs of SCO 5 and 6, the kewlest > part about that, and one reason I don't want webproxies on my lawn, is > because I make those archives available exlusively via Gemini (Maybe > Gopher too, I'll have to check lolz). Point being, Vger gets a couple of > folks downloading old SCO .iso's every month, and it seems to go fine > without compression. Would compression be nice? - you betcha! but at > 1Gbps it's not really that big of a deal - at least for now. If you want to transfer files over an uncommon protocol that most people can't use, have you considered (S)FTP? Chrome dropped FTP support in version 88 and version 89 is the current version. (Personally, I'm amused by how FTP has become _indie_ in the span of a year or two. NNTP and Gopher threw a great welcoming party.) Also: why would you want to burden Gemini-client implementers with having to handle transfer encodings when you can just gzip (or .xz, or whatever the new hotness is) for small numbers of largish files? That sounds like a lot of server-writer-hours (implementing it) and client-author-hours (also implementing it) and server-admin-hours (turning it on for some files and leaving it off for others) for a tiny handful of users who can get manifestly better compression ratios by using an external compression program. I'd much rather have three more good (or even passable) Gemini clients _for OSs I'll never use_ than to have my favorite clients and servers all using a transfer encoding like gzip or brotli.
---
Previous in thread (13 of 16): 🗣️ Bradley D. Thornton (Bradley (a) NorthTech.US)
Next in thread (15 of 16): 🗣️ Bradley D. Thornton (Bradley (a) NorthTech.US)