💾 Archived View for rawtext.club › ~sloum › geminilist › 006709.gmi captured on 2024-03-21 at 16:19:33. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Francis Siefken fsiefken at gmail.com
Thu Jun 17 13:24:45 BST 2021
- - - - - - - - - - - - - - - - - - -
Attál gemininauts,
Gemini appeals to me as someone who likes plain text and keeping thingssimple. It also evokes a huge nostalgia for the days of gopher, bbs andslow packet radio links.Suppose there were a few shielded and solar powered Raspberry Pico basedGemini servers in orbit with radio transmitter and receiver. The longdistance bandwidth would be a scarce resource and timeouts can happenfrequently. There's HTTP has compression, BBS has zmodem, there's the Squidproxy. Caching and compression have been discussed before. I want to focuson compression as it surprises me as the remarks seem to be to dismissiveeven though compression was a huge thing in the early days of popular datanetworks (fidonet, bbs, simtel).
On March 10, 2021 Bradley D. Thornton remarks "neither of those two things(Accessibility or gzip compression) have anything to do with, nor have anyplace in discussions, for spec changes" and argues:* "Gemini is intended (expected, rather) to deliver mostly small files"* "Would compression be nice? - you betcha! but at 1Gbps it's not reallythat big of a deal - at least for now" and Solderpunk remarked earlier on the 16th of January 2020:"compression is not a bad thing, but for small content the benefit is notproportionate to the implementation effort".
I'm not sure about that.I agree that Gemini is not about efficient transfer of files, there'sbittorrent, IPFS and plain http for that. For me it's about transferringtext as simple and effectively as possible. As Gemini is also aboutcreativity and focus through limits, I want to to test the Gemini design inconstrained bandwidth situations for example at sea or in space with 1200bps on a low power Raspberry Pico or perhaps even on the computer and radioof the Gemini capsule in 1965. Loading twelve Kbyte SF story wouldn't loadinstantaneous.Fortunately Unicode can be compressed substantially. So I wondered ifcompression could somehow be implemented easily without breaking theminimalist design philosophy. Of course one could use Mosh and SSH to starta terminal Gemini client on a host with higher bandwidth (or use lzocompression in OpenVPN), but it would be elegant if the decompressionhappens transparently in Gemini without using additional ssh or openvpnservers.It also would be a sport to get gemtext to the client as fast astechnically possible, ideally below the threshold of noticing there hasbeen a network transfer at all.
One simplistic idea is to check if the gmi is binary, and assume it hasbeen compressed with zstd and then automatically decompress it in theclient. It'd be just one extra step in the gemini client.To assess thethe speed and data savings I compressed a short story by GeneWolfe with zstandard and lpaq9, a page or so, representative of an averagegemtext. The compression and decompression speeds are below 30ms here. Ididn't precompress with a dictionary (for added significant size reduction)as that would mean detecting the language (from for example wordfrequency). Ideally the gmi would be compressed one time on the server toavoid compressing (and straining the solar powered pico on space) for eachrequest.
11390 xicygnus.gmi4098 xicygnus.gmi.0.lpaq94855 xicygnus.gmi.13.zst5146 xicygnus.gmi.3.zst
How would people solve such use cases elegantly and within the designphilosophy?
I tried to find out the data rates from the pictures of the Apollo moonmissions, but only found this:"For a typical Apollo launch, Cape Kennedy is connected directly to theMission Control Center, Houston, by NASCOM's Apollo Launch Data System, acombination of data gathering and transmission systems designed to handlelaunch data exclusively. A high speed data (2400 bit per second) lineconnects the Cape to Goddard. At Goddard the transmission rate is increasedto 40,800 per second rate from there to Houston."http://web.mit.edu/digitalapollo/Documents/Chapter8/apollomsfn.pdf
kind regards,Francis Siefken (NL)gemini://fsiefken.srht.site-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210617/ab1b2245/attachment.htm>