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
---
Previous in thread (13 of 55): 🗣️ John Cowan (cowan (a) ccil.org)