Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)

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

---

Previous in thread (45 of 55): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)

Next in thread (47 of 55): 🗣️ marc (marcx2 (a) welz.org.za)

View entire thread.