Caching and status codes

[bie]

On Fri, Nov 06, 2020 at 10:55:50PM -0500, John Cowan wrote:
> On Fri, Nov 6, 2020 at 10:48 PM bie <bie at 202x.moe> wrote:
> 
> 
> > This reduces gemini to a simple file sharing protocol and basically says
> > that dynamic content is out (unless only targeting advanced clients).
> >
> 
> Here are my assumptions.
> 
> 1) Clients are going to cache, like it or not.  Some already do.
> 
> 2) Servers are in the best position to say whether content is dynamic or
> not. "Dynamic" in this case is not just CGI-generated; it's also static
> files that change often.  (I post a static file on the Web that is
> recomputed every ten minutes by a cron job.)
> 
> 3) If the server can communicate "don't cache this", the client can provide
> a better UX.

1) Rude clients are going to cache, yes.

2/3) Totally agree, just not about what the default should be 🤔

And just to keep this "grounded", here are some examples of stuff that
arbitrary caching would break:

- Adventure games that keep state in the client cert and update the
  response not only on user input
- The URL on my personal gemini site that responds with a random photo
- Guestbooks
- Streaming content

Meanwhile, a default of not caching anything doesn't break anything. All
it does is degrade the UX (minimally, IMO).

> Ultimately, I like the gemini protocol just the way it is (and wouldn'
> > be opposed to even a 1000 year feature freeze) but arbitrary caching by
> > clients kills a whole host of use-cases around generated and dynamic
> > responses.
> >
> 
> That horse has sailed and that ship is out of the barn.  "The world will go
> as it will, and not as you or I would have it."

Well, yes, fair enough. But gemini is only a tiny part of the world. If
the aesthetic sensibilities of the community turn out to conflict with
mine it's easy to look away ;)

bie