It was thus said that the Great khuxkm at tilde.team once stated: > November 7, 2020 8:15 PM, "Ali Fardan" <raiz at stellarbound.space> wrote: > > On Sat, 7 Nov 2020 13:42:57 -0500 > > John Cowan <cowan at ccil.org> wrote: > > > >> If you are browsing with netcat, caching is not even an issue. If > >> nobody wanted to serve dynamic content, 22 wouldn't be useful. It is > >> handy for those who do want to, to communicate their intent. No > >> client and no server has to implement this. > > > > If 22 is explicit no caching response, how would 20 be redefined? > > 20 wouldn't be redefined. A status code of 20 would simply have no > assumptions as to the cacheability of a resource (i.e; cache at your own > risk). Meanwhile, 21 and 22 would be there for CGI, etc. that can return > them. Ah, clashing proposals! How wonderful! In another thread, not at all related to caching, we have prisonpotato at tilde.team who said: > This seems like a neat solution to this problem to me, but I'm not sure if > it would work at this stage of gemini's life cycle. There are also of > course the issues with dynamically sized responses as generated by CGI > scripts and stuff like that, so maybe we could introduce a new response > code, like 22: Response with size. > > 20 text/gemini > 22 100 text/gemini > > This solves both problems by making content length optional again, but > exposes a risk that this type of extension could be used to add more fields (gemini://gemi.dev/gemini-mailing-list/messages/003010.gmi) and John Cowan, who said this in this thread: > 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. So, which is it? Sizes? Or caching? Or I suppose we could all the above: 20 status, no size 22 status, size 21 cache, no size 22 cache, size 23 no-cache, no size 24 no-cache, size and before you know it: 20 status, no size, no future feature 22 status, size, no future feature 21 cache, no size, no future feature 22 cache, size, no future feature 23 no-cache, no size, no future feature 24 no-cache, size, no future feature 25 status, no size, future feature 26 status, size, future feature 27 cache, no size, future feature 28 cache, size, future feature 29 no-cache, no size, future feature 30 no-cache, size, future feature ... oh, wait a second ... We're done out of status codes and crashing into the next block. It may seem silly to worry about future feature now, but hey, the future comes eventually. Even *if* the size doesn't get its own status code, I think my argument stands---features can mix, and if they can mix, the number of status code explodes: 20 status 21 cache 22 no-cache 23 status, future feature 1 24 cache, future feature 1 25 no-cache, future feature 1 26 status, no future feature 1, future feature 2 27 cache, no future feature 1, future feature 2 28 no-cache, no future feature 1, future feature 2 29 status, future feature 1, future feature 2 30 ... uh oh ... I have my own ideas about caching, but I want to cobble up a proof-of-concept first before I talk about it more, because from where I come from, working code is worth more than talk. -spc
---
Previous in thread (26 of 55): 🗣️ khuxkm (a) tilde.team (khuxkm (a) tilde.team)
Next in thread (28 of 55): 🗣️ khuxkm (a) tilde.team (khuxkm (a) tilde.team)