Caching and status codes

[bie]

> 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