On Fri, Nov 06, 2020 at 05:19:18PM -0500, John Cowan wrote: > On Fri, Nov 6, 2020 at 5:11 AM Philip Linde <linde.philip at gmail.com> wrote: > > > > I think that's the advantage of bie's suggested solution. It doesn't > > require any breaking changes, and a client that doesn't recognize the > > difference between codes 20 and 21 will still be fully compatible with > > a server that does. > > > > I agree, except that I am in favor of code 22 meaning "It is inadvisable to > cache this", on the assumption that most Gemini documents are static and > will continue to be so. Even on the Web, most documents are static. If > there is to be just one new code, better it should be 22. If people feel > strongly about 21, then both 21 and 22. > This reduces gemini to a simple file sharing protocol and basically says that dynamic content is out (unless only targeting advanced clients). Ultimately, I like the gemini protocol just the way it is (and wouldn't 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. bie
---
Previous in thread (11 of 55): 🗣️ John Cowan (cowan (a) ccil.org)
Next in thread (13 of 55): 🗣️ John Cowan (cowan (a) ccil.org)