> This is the creativity I like to see when dealing with limited > environments, this is a solution that requires no change in the > protocol, if a client developer feels the urge to have caching which I > still don't understand why it should be necessary for Gemini. (everybody > refused to give me an answer) > > Great solution, but I doubt anyone would listen to you considering the > current climate of discussion being focused heavily on adding more. I really like this approach, as I like the protocol as-is. I am currently working on a client for Android, and I am planning to make heavy use of caching, although I do not think a change in the protocol is necessary. In my usecase, I have a dataplan that's free, but just gives me flaky 32kbit/s at best, usually far less. (It's called "messaging option"). Loading a page on Gemini usually takes multiple seconds. This would be similar for packet radio and similar applications. Without caching, this is a huge PITA. I will take care to have a "Reload" button once I use caching, so the users themselves can decide when new content should be fetched. I want to stress that caching is neccessary in my usecase. It's a much more needed feature than, say, client certificate support. At the moment, the majority of Content on Gemini is static and I believe it will continue to be. - Waweic
---
Previous in thread (41 of 55): 🗣️ Sudipto Mallick (smallick.dev (a) gmail.com)
Next in thread (43 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)