Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)

[khuxkm at tilde.team]

November 8, 2020 12:18 AM, "Sean Conner" <sean at conman.org> wrote:

> 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
> 
> (https://lists.orbitalfox.eu/archives/gemini/2020/003010.html)
> 
> 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

This can't happen, though, because the first proposal breaks the compatibility of <META> in response codes within a block, and the second one is just debating which of the codes we should add.

Cache/no-cache would be 2 (at most) response codes. That's all.

I'm also going to try and put together some basic code to demonstrate how I think this should work. Maybe, then, it'll be a bit clearer.

Just my two cents,
Robert "khuxkm" Miles