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

[Ali Fardan]

On Sun, 8 Nov 2020 11:29:09 +0530
Sudipto Mallick <smallick.dev at gmail.com> wrote:
> This is what I *think* how *should* clients work with caching:
> 
> The clients with history support and supports going ''backwards'' and
> ''forwards'' through history should cache text/* responses in memory
> for that browsing session. When the user browses through the history
> using ''forward'' and ''backward'' action, no reloading should happen.
> But, when a user clicks the link for a resource already in cache or
> writes the link by hand or selects the link from previously visited
> links or asks for reload: the cache is purged and the resource
> reloaded. It is assumed that requests with query part are idempotent.
> Now, when a page is dynamic, it should be stated as such so that the
> user would reload that page.
> With that, no new response codes.


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.