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

[Waweic]

> 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