Caching and status codes

I *love* it when clients cache stuff, for performance and environmental reasons.

But I think that's something that each individual client (or client
dev, I suppose) should deal with in their own fashion and only if they
want to. As mentioned before most files served on gemini:// are small
text files, and it's likely to remain that way for the foreseeable
future. I don't think caching is something that the protocol should
care about or cater to specifically, as it adds complexity and
ambiguity.

> Now, I don't see the need for caching at all when it comes to
> gemini, but if it's something the gemini community wants or needs then
> I'd like to suggest a 2x status code that let's a client know that the
> response is unlikely to change and thus cacheable. This could even kind
> of match how the temporary/permanent redirect status codes are defined:
>
> 20 - SUCCESS
> 21 - "PERMANENT" SUCCESS (Feel free to cache this)

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?

As mentioned in previous discussions on caching and checksums, there's
not really room in the protocol specification for the needed
information unless you start misusing MIME type info. I've come around
to thinking that the added complexity, ambiguity, and possibly
breaking changes far outweigh the added benefit.

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)

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.

The only real benefit of caching would be on the server side; whether
it's in a proxying situation or some type of mirror, or just a server
that wants to be speedier when serving dynamic data. I don't see a
need for a protocol change for that, though; if someone wants to make
a super fancy app server they're free to do it as long as it looks the
same to clients :)

Cheers,
ew0k

---

Previous in thread (2 of 55): 🗣️ Sudipto Mallick (smallick.dev (a) gmail.com)

Next in thread (4 of 55): 🗣️ bie (bie (a) 202x.moe)

View entire thread.