Caching and status codes

[mbays at sdf.org]

* Friday, 2020-11-06 at 14:52 +0900 - bie <bie at 202x.moe>:

>There's been some light discussion on the gemini irc channel about if
>and how clients should cache gemini responses, and I'd love to hear how
>people here think about the issue...

Since gemini requests have no guarantee of idempotency, I think it's 
crucial that the user always knows whether an action will cause 
a request or not. That means simple consistent rules on whether to 
retrieve from cache or make a request, that don't depend on subtleties 
like the current time or RAM availability. One simple way to achieve 
this is to always make a fresh request *except* when navigating history 
("back" or "forward"). You could also interpret navigating to an url 
which is in (linear) history as navigation of history, so load from 
cache (in theory this does require unbounded memory use to store the 
urls of an unboundedly long history list, but in practice this is 
unlikely to be more than a few KB). If the page you want to load from 
cache has been deleted due to memory constraints, I'd say you should 
present an error and offer to let the user make the request again, 
rather than doing it automatically. But if all but the tail is 
text/gemini, probably you can afford to store everything anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/378c00b5/attachment.sig>