Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)
bie
bie at 202x.moe
Mon Nov 9 02:22:47 GMT 2020
On Sun, Nov 08, 2020 at 05:21:17PM +0000, Waweic wrote:
> 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.
I should add that in cases where there's an actual need for caching like
this, caching is totally fine by me, but I hope you can find a way to
add some kind of indicator to make it clear to the user whether you're
showing fresh or cached content!
bie
More information about the Gemini
mailing list