💾 Archived View for rawtext.club › ~sloum › geminilist › 006734.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Francis Siefken fsiefken at gmail.com
Sat Jun 19 10:34:28 BST 2021
- - - - - - - - - - - - - - - - - - -
Hi Christian, on Sa 19 jun. 2021 09:15 Christian Seibold <krixano at mailbox.org> you wrote:
The last person who emailed on the mailing list was Johann Galle, not me.
I know, in my previous message replied specifically to your message vr 18june 14:24. Is there something wrong with that?
Please read my own response again.[..]
If you're using zips, Lagrange doesn't take 4 user actions, it takes 1.
I understood what you meant yesterday. But in my test with Langrange 1.5.2and gmnisrv it took 4 steps. With the reference gpub (excellent choice) ittakes 3 steps and it opens an addititional tab. With a gmi zip it says:"xi.zip is a compressed archive. You can save it as a file to yourDownloads folder: press Ctrl+S or select "Save to Downloads" from themenu." And then a whole lot more steps. I wish it would take zero steps anda client would for example automatically gunzip a gmi.gz and display itinline immediately by default.
Browsers should implement this, not the protocol. It's that's simple
Will it be? For example Asuka, Amfora, Ariane and Lagrange are nicebrowsers but if I read the discussion so far I am sure it will beimplemented in the way I envision. Images and sounds are handleddifferently and take at least one or a few user actions. What I hope andwish for is that one day my Gemini capsule can serve index.gmi.zstd orindex.gmi.ppmd transparently. I trust they can be automaticallydecompressed inline in the same tab by visiting browsers, either throughthe mime-type route, TLS compression or through a Gemini Content-Encodingand zstd or ppm server side compression.You mentioned the dogma browsers should implement this and not theprotocol. I am curious as to what your reason for this is other then thatgemini protocol is supposedly set in stone?Protocol support has been discussed on list before. On March 10, 2021Bradley D. Thornton had a similar remark "neither of those two things(Accessibility or gzip compression) have anything to do with, nor have anyplace in discussions, for spec changes" and argued:* "Gemini is intended (expected, rather) to deliver mostly small files"* "at 1Gbps it's not really that big of a deal" and Solderpunk wrote 16th of January 2020:* "compression is not a bad thing, but for small content the benefit is notproportionate to the implementation effort".
But both arguments do not apply in low bandwidth situations (in a forest orin space), even with an 2000 byte mail like mine you get at least a 50%reduction which in some situations in space or remote places couldtheoretically mean life or death. IMAP has compression, HTTP hascompression (for examplee Content-Encoding: zstd, rfc8478). How hard is itreally, a few extra lines in the server?I'd think it's not much harder then getting mime-type handling consistentlyimplemented in Gemini browsers (which in my original post means zero stepsfor compressed gemtext). TLS 1.3 has compression on board, it's a securityrisk in HTTP session hijacking and all HTTP browsers have turned it off.But this security risk doesn't apply to Gemini or with SMTP or IMAP. Thiswould be another way to making this compressed gemtext vision work. Even inVinton Cerf's interplanetary DTN bundling protocol compression plays arole, so why not in the space inspired Gemini protocol if it can be doneeasily? And if not, of course I appreciate the basic answer of keeping itsimple. But how simple is the proposed alternative really? The Gempubdoesn't load immediately and I suspect there will always be the extradownload and open step. Of course I can send patches, fork browsers or rollmy own gemini client and encourage people to additionally compress theirindividual gemtexts with PPMd and their capsule with Gempub.
regards,Francis Siefken (NL)gemini://fsiefken.srht.site-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210619/eaccb15d/attachment-0001.htm>