> Adding a response code like that is counterproductive, I believe, as > there's really no way for a server to determine what sort of file or > data is unlikely to change, and there's no way for a client to > determine what a flag of "unlikely to change" means. Does it mean it > won't change in the next hour? The next month? If there's no way for a server to determine what's unlikely to change then it's *definitely* no way for a client to know, in which case caching the response is just plain bad-mannered. > On a side note I am (somewhat slowly) playing around with > python3/Tkinter to make a client, and my current thinking for the > design of that is that when the user clicks a link that returns an > image I'll display it inline and cache it (based on its path) > *forever*, though it will be clearly marked as a cached resource in > the UI somehow as of yet undetermined. As for text/gemini I don't see > a reason to cache them for more than very short periods: they're too > small and frequently changed. No changes are needed in the protocol > for this sort of behaviour, and I'm not really convinced it's a > behaviour most clients should adopt either. Client-side caching is > something that users have strong opinions about. I definitely have strong opinions about this, yeah - this would, like I mentioned earlier, mean that my script returning a random photo wouldn't work in your client, and that a lot of the tools and toys I was hoping to use the gemini protocol for are probably suited for something else, at least if the consensus among the gemini community is that arbitrary caching is fine. ?? bie
---
Previous in thread (4 of 55): 🗣️ bie (bie (a) 202x.moe)
Next in thread (6 of 55): 🗣️ Björn Wärmedal (bjorn.warmedal (a) gmail.com)